Android Security Architecture
description
Transcript of Android Security Architecture
![Page 1: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/1.jpg)
Android Security Architecture
Security goals• Protect user data • Protect system resources (hardware, software) • Provide application isolation
Foundations of Android Security Application Isolation and Permission Requirement• Mandatory application sandbox for all applications • Secure inter-process communication • System-built and user-defined permissions • Application signing
![Page 2: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/2.jpg)
![Page 3: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/3.jpg)
Android software stack
• Each component assumes that the components below are properly secured.
• All code above the Linux Kernel is restricted by the Application Sandbox
• Linux kernel is responsible sandboxing application – “mutually distrusting principals”– Default access to only its own data
• The app Sandbox apps can talk to other apps only via Intents (message) , IPC, and ContentProviders
• To escape sandbox, permissions is needed
![Page 4: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/4.jpg)
1. Security at the Linux kernel
• A user-based permissions model • Process isolation: Each application has its sandbox
based on separation of processes: to protect user resources from each another; each runs in its own Linux process to secure Inter-Process communication (IPC)
Ex:• Prevents user A from reading user B's files • Ensures that user A does not access user B's CPU,
memory resources • Ensures that user A does not access user B's devices
(e.g. telephony, GPS, Bluetooth)
![Page 5: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/5.jpg)
Application Sandbox
• The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process.
• When launching a new Activity, the new process isn’t going to run as the launcher but with its own identity with the permission specified by the developer.
• The developer of that application has ensured that it will not do anything the phone’s user didn’t intend. Any program can ask Activity Manager to launch almost any other application, which runs with that application’s UID.
• Ex. application A is not allowed to do something malicious like to read application B's data or dial the phone without permission.
• All libraries, application runtime, and all applications run within the Application Sandbox in the kernel.
![Page 6: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/6.jpg)
Permissions and Encryption
• Permissions In Android, each application runs as its own
user. Unless the developer explicitly exposes files to other applications, files created by one application cannot be read or altered by another application.
• Password Protection Android can require a user-supplied password
prior to providing access to a device. In addition to preventing unauthorized use of the device, this password protects the cryptographic key for full file system encryption.
![Page 7: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/7.jpg)
Encryption
• Encryption
Android 3.0+ provides full filesystem encryption, so all user data can be encrypted in the kernel
• For a lost or stolen device, full filesystem encryption on Android devices uses the device password to protect the encryption key, so modifying the bootloader or operating system is not sufficient to access user data without the user’s device password.
![Page 8: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/8.jpg)
2. Android Application Security(Application framework)
• Almost all Android applications are written in the Java and run in the Dalvik virtual machine. However, applications can also be written in native code.
.java -> .class -> .jar -> .dex Android application deployed in a single .apk file.• Android middleware is based on the Linux kernel. It
provides several native libraries and a Dalvik virtual machine (DVM) instead of Java virtual machine (JVM) for its applications’ runtime environment where application isolation is enforced.
• The Java written Android middleware provides development APIs, the system service, all basic phone device functionalities
![Page 9: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/9.jpg)
Configurations of Android applications
• The AndroidManifest.xml file is the configuration file of Android application.
• It specifies the components in the application and external libraries it uses.
• It tells the system what to do with activities, services, broadcast receivers, and content providers in an application.
• It declares permissions it requests as well as permissions that are defined to protect its own components. The client must be granted such permission in order to run the application.– Without user’s consent application will not be
installed
![Page 10: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/10.jpg)
Android Security Basics - Android Manifest• Applications have no permission required by default• Each application can declare the requiRED permissions
<?xml version="1.0" encoding="utf-8"?><manifest . . . > <application . . . > <activity android:name="com.example.project.myActivity" <intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter> . . .
</activity> <activity> ….. </activity>
<uses-permission android:name="android.permission.SEND_SMS" /> <uses-permission android:name="android.permission.INTERNET" /> . . .
</application></manifest>
![Page 11: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/11.jpg)
Android Permission Model• Permissions are the core concepts in the Android
security to control the access from one application component to another.
• All permissions are set at installation time and can’t change until the application is reinstalled.
• Android’s permission only restricts components
from accessing resources• E.g. an application needs the READ_CONTACTS
permission to read the user’s address book • If a public component doesn’t explicitly declare any
access permission, Android permits any application to access it.
![Page 12: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/12.jpg)
• All sensitive APIs listed below are intended for use by trusted applications and protected through Permissions such as functions for camera, bluetooth, telephony, SMS/MMS, network connections
• All permissions are granted at install-time. • In order to be granted a permission, it should be requested in the
Android manifest file when specifying properties for an application, system then evaluates it and makes a final decision on whether to grant or deny.
• After the application has been launched, permission checks are enforced before the actual access take place.
• If the user continues the installation, the system grants all requested permissions. The user can not grant or deny partial permissions afterwards.
• More than 60 system built-in permissions defined in the form of android.Manifest.permission.X, where X is the name of a particular permission.
• The system default permissions are described at https://developer.android.com/reference/android/Manifest.permission.html.
![Page 13: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/13.jpg)
• Create app’s own permissions (called dynamic permissions in Android) through permission declaration in AndroidManifest.xml.
• permission declaration <permission> is the place where developers are able to define their own permissions for protecting their application-specific APIs or components.
• The name of permission needs to be globally unique and descriptive so that other components are able to know and request it by name.
• <use-permission> lets the developer to request a permission so they get access to certain functionalities in the system. It could either be a built-in permission or a dynamic permission. All permissions should be requested explicitly.
• Once granted, the permissions are applied to the application as long as it is installed. Permissions are removed if an application is uninstalled, so a subsequent re-installation will start over again permission request.
• Users are able to view permissions and can also turn off some functionality globally when they choose, such as disabling GPS, Radio, or, SMS, Wi-Fi.
![Page 14: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/14.jpg)
Built-in Permission
• Default Android Permissions Policy: No app can do anything to adversely Install/uninstall/modify other apps, use other apps private components, access network, users data (contacts, SMS, email),
use cost sensitive APIs (phone calls, send SMS, …)
• Built-in Android Permissions CALL_PHONE, CAMERA, INTERNET, READ_CONTACTS, READ_LOGS, READ_SMS, RECEIVE_SMS, R SEND_SMS,
WRITE_SMS
• Caller must have a certain permission• e.g., <uses-permission
android:name="android.permission.CALL_PHONE"> </uses-permission>
![Page 15: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/15.jpg)
The protection level From weak to strong:Normal• Normal permissions are the default setting If the
protection level is not specified, providing the weakest protections.
• They are often used to protect less security-critical functionalities. the permission is assumed to be normal. When a normal permission is requested, the system grants it without asking users.
Dangerous• Permissions at this level might ask for accessing the
user privacy or certain hardware service. An example for dangerous permissions is asking for accessing some functionalities cost money.
• When an application requests a dangerous permission, the system shows the permission information in a screen to users and users need to accept all permissions if they want to install the application on their phones.
• Granted during installation, requires user approval
![Page 16: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/16.jpg)
Signature• Decided by the system without the users’
involvement. To be granted a signature permission, the requesting application must be signed by the same key as the application that the permission protects.
• Granted only if requesting app is signed by the same developer that defined the permission
• Useful for restricting component access to those apps under the control of the same developer
SignatureOrSystem Granted if requesting app meets the Signature
requirement OR if app is installed in the system application folder
![Page 17: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/17.jpg)
3. Security for Inter-Process Communication
In addition to any Linux-type process communication mechanisms such as file system, local sockets, signals Android provides new IPC mechanisms:
3.1 Binder
Remote procedure call( RPC) mechanism (Remote method invocation) designed for in-process and cross-process calls. https://developer.android.com/reference/android/os/Binder.html.
Secured by caller permission or identity check.
![Page 18: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/18.jpg)
Cont.• AIDL (Android Interface Definition Language) is
an IDL language used to generate code that enables two processes on an
Android-powered device to talk using inter-process communication (IPC).
• Ex. an Activity needs to call methods on an object in another process (for example, a service), you would use AIDL to generate code to marshall the parameters.
• The AIDL IPC mechanism is interface-based, similar to COM or CORBA, but lighter weight. It uses a proxy class to pass values between the components
![Page 19: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/19.jpg)
3.2. Intents
• An Intent is a simple notification message object that represents an "intention" to do something.
• It is serialized when it is sent. The message consists of the data together with the action operation that will be performed.
• Intent filters are used to filter out unwanted intents so that users are informed by interested ones only.
• For example, if your application wants to display a web page, it expresses its "Intent" to view the URL by creating an Intent instance and handing it off to the system. The system locates the Browser that knows how to handle that Intent, and runs it; or to broadcast interesting events (such as a notification) system-wide.
![Page 20: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/20.jpg)
Cont.• Intent: notification from one process to another• directed intent: has one specific recipient• broadcast intent: can be received by anyone• intent filter: a list of intents an activity/service is
interested in
for example, a application wants to make a phone call: Intent myCallIntent = new Intent(Intent.Action_CALL); myCallIntent.setData(Uri.parse(“tel:123456789”); startActivity(myCallIntent);
![Page 21: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/21.jpg)
Cont.• “Three of the core components of an application —
activities, services, and broadcast receivers — are activated through messages, called intents. Intent messaging is a facility for late run-time binding between components in the same or different applications.”
• “The Android system finds the appropriate activity, service, or set of broadcast receivers to respond to the
intent, instantiating them if necessary”.
![Page 22: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/22.jpg)
Cont.
• Broadcast intents are delivered only to broadcast receivers, never to activities or services. An intent passed to startActivity() is delivered only to an activity never to a service or broadcast receiver,
• Intent messages contain a recipient and data (optional) which Link applications and form the foundation of the message passing system
• Used for intra- and inter-app communication and system-wide notifications (system broadcast Intents)
• Are divided to explicit and implicit components– Explicit: specifies a definite application– Implicit: specifies a kind or categories
![Page 23: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/23.jpg)
Intent action constant
• ACTION_CALL to Activity: Initiate a phone call• ACTION_EDIT to Activity: Display data for the user to
edit• ACTION_MAIN to Activity: Start of a task• ACTION_BATTE RY_LOW to Broadcast receiver: A
warning on low battery
![Page 24: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/24.jpg)
Intent in IPC
• Activities, Services, and Broadcast Receivers can send/receive Intents
• Intents (explicit & implicit) can– Start Activities– Start, stop, and bind Services– Broadcast information to Broadcast Receivers
• To receive Intents, component must be declared in the manifest
• By default, components can only receive internal Intents
• Asynchronous comm.• Not secured on the carried data
![Page 25: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/25.jpg)
Intent Filters
• To inform the system which implicit intents they can handle, activities, services, and broadcast receivers can have one or more intent filters.
• Each filter describes a capability of the component, a set of intents that the component is willing to receive.
• It filters intents of a desired type, while filtering out unwanted intents
• Activity with intent filter enabled is “exported” out
![Page 26: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/26.jpg)
3.3 Security Risks in Android’s Inter-Application
• Attacker can intercept the message If sender does not correctly specify recipient,
can hijack activity, service, broadcast via intent to lead to a malicious target
• Attacker can inject code If Component does not restrict from whom it can receive messages
![Page 27: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/27.jpg)
Attacks• Only consider attacks on exported components
– Consider non-exported components and exported components with a Signature (or higher) permission level to be private and not susceptible to the below attacks
• Type 1 - Intents sent to the wrong application– Can leak data– Broadcast theft, activity and service hijacking
• Type 2 – Receiving external Intents– Data corruption, code injection– Malicious broadcast injection, malicious activity
launch, malicious service launch
![Page 28: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/28.jpg)
Type 1 – Broadcast Theft• Broadcasts (via implicit Intent) vulnerable to eavesdropping
and denial of service attacks• Eavesdropping
– A public broadcast can be intercepted by attacker because a loose intent filter leaves a hole and no confirmation checking
![Page 29: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/29.jpg)
• Denial of Service– Ordered broadcast vulnerable– Attacker resets its priority to highest level to alter the
broadcast receiving order which can cancer or inject malicious code or data
![Page 30: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/30.jpg)
Type 1 – Activity and Service Highjacking
• Malicious a/service is activated instead of desired components such as by Phishing
• Android will select a best matched one If multiple activities have the same Intent filter spec so that The attacker may return malicious code or data to the user
![Page 31: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/31.jpg)
Type 2 – Malicious Injection
Activity• A malicious activities can be activated by Intents
(explicit or implicit) as results of injection – tamper data or Leak sensitive information
Broadcast• Broadcast receivers registers with a malicious
broadcast provider and take system action to make itself open to public
• An system action string that only the system can add may be injected
![Page 32: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/32.jpg)
Some Recommendations
• Use caution with implicit Intents and exporting Components
• Use explicit Intents to send private data• Use explicit Intents for internal communication• Returned results should be checked for authenticity• Avoid exporting Components• The same Component should not handle both internal
and external Intents
![Page 33: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/33.jpg)
Android developers should securing user data and avoiding the introduction of security vulnerabilities. Always assign a least permission to a application
Cost-Sensitive APIs• A cost sensitive API is any function that might generate a
cost for the user or the network. The Android platform has placed cost sensitive APIs in the list of protected APIs controlled by the OS. The user will have to grant explicit permission to third-party applications requesting use of cost sensitive APIs for SIM Card Access, Device Metadata, Sensitive Data via Input Devices or Personal Information
These APIs include:• Telephony • SMS/MMS • Network/Data • In-App Billing
![Page 34: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/34.jpg)
4. Application Signing
• Code signing allows developers to identify the author of the application and to update their application without creating complicated interfaces and permissions.
• Every application that is run on the Android must be signed by the developer.
• Applications that attempt to install without being signed will rejected by either Google Play or the package installer on the Android device.
![Page 35: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/35.jpg)
• On Android, application signing is the first step to placing an application in its Application Sandbox. The signed application certificate defines which user id is associated with which application; different applications run under different user IDs.
• Application signing ensures that one application cannot access any other application except through well-defined IPC.
• When an application (APK file) is installed onto an Android device, the Package Manager verifies that the APK has been properly signed with the certificate included in that APK.
• If the certificate (or, more accurately, the public key in the certificate) matches the key used to sign any other APK on the device, the new APK has the option to specify in the manifest that it will share a UID with the other similarly-signed APKs.
![Page 36: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/36.jpg)
• Android requires every application to be signed. The main purpose of application signing is to distinguish applications from one to another.
• Developers sign apps with their own private keys. The private keys are supposed to stay secret and known only to their owners.
• After a signed application is installed on the phone, the system is able to use its signature information to distinguish it from other application.
![Page 37: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/37.jpg)
Signature protection level
• Signature shows app persistence:
Check: app is changed or updated with diff sig.• Signature shows the authorship and trust for application• All Android applications must be signed, but are self-
signed• Why self signing? Market ties identity to developer
account– No applications are trusted.
![Page 38: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/38.jpg)
Android App Signature
• What does signing determine?– Shared UID for shared keys– Self-updates
Google doest not have central control over the app’s signature certificates– creates chain of trust between updates and among
applications– In signature schemes, the private key is used to sign
a app or message; anyone can check the signature using the public key.
![Page 39: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/39.jpg)
Cont.
• All .apk files must be signed with a certificate– identifies the author of the application. – does not need to be signed by a certificate authority
• allows the system to grant or deny applications – access to signature-level permissions– request to be given the same Linux identity as another
application.
• If the public key matches the key used to sign any other APK, the new APK may request to share a UID with the other APK.
![Page 40: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/40.jpg)
SMS Vulnerabilities
– SMS• Short Messaging System• Very commonly used protocol• Used to send "Text Messages"
– GSM uses 2 signal bands, 1 for "control", the other for "data".
– SMS operates entirely on the "control" band.– High volume text messaging can disable the "control"
band, which also disables voice calls.– Can render entire city 911 services unresponsive.
![Page 41: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/41.jpg)
Bluetooth Vulnerabilities
– Bluetooth• Short range wireless communication protocol• Used in many personal electronic devices• Requires no authentication
– An attack, if close enough, could take over Bluetooth device.
– Attack would have access to all data on the Bluetooth enabled device, bluesnarfing
![Page 42: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/42.jpg)
Information Misuse by Apps
• Phone identifiers: phone number, IMEI (device identifier), IMSI (subscriber identifier), and ICC-ID (SIM card serial number).
• Phone identifiers are frequently leaked through plaintext requests.
• Phone identifiers are used as device fingerprints.• Phone identifiers, specially the IMEI, are used to
track individual users.• Phone identifiers are sent to advertisement and
analytics servers.
![Page 43: Android Security Architecture](https://reader033.fdocuments.net/reader033/viewer/2022051002/568158cc550346895dc6175d/html5/thumbnails/43.jpg)
Reference
• Android Security, CEG436: Mobile Computing• Prabhaker Mateti• Android Security Overview, source.android. com/tech/security/• Nils, “Building Android Sandcastles in Android’s Sandbox,” Oct
2010, BlackHat• William Enck, Damien Octeau, Patrick McDaniel, and Swarat
Chaudhuri, “A Study of Android Application Security”, 20th USENIX Security, Aug 2011
• Android Security Overview http://source.android.com/tech/security/index.html• “Analyzing Inter-Application Communication in Android” by Chin,
Felt, Greenwood, and Wagner (UC Berkeley)• http://www.comdroid.org/• Donald E Frederick, Android’s Inter-Application Model and Security
Risks, 8/20/2012