Week 6 - Understanding the Security Model

Question 1

Security Model

Answer 1

To prevent unauthorized access to an application’s data by other applications running on the same device.

One application cannot negatively impact the operation of another without proper consent, creating what is known as the application sandbox.

Verifying an application’s identity is essential to maintain trust boundaries and prevent unauthorized claims of identity, such as impersonating Google. This identity verification is managed through code signing

Question 2

Code Signing

Answer 2

A cryptographic process using digital certificates.

Private keys of these certificates are held by application developers.I

It helps prove the identity of an application’s author and establish trust in the security model.

All Android packages, or APK files, must be signed, even during development using a default debug certificate.

Question 3

Certificate Creation

Answer 3

Developers can create their own certificates for signing.

$ keytool -genkey -v -keystore mykey.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

Question 4

Signing Process

Answer 4

Sign an unsigned application using your certificate.

$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore application.apk alias_name

Question 5

Certificate Information

Answer 5

Stored in the CERT.RSA file within the META-INF folder of the Android package.

Question 6

Absence of Central Authority Verification

Answer 6

Android OS doesn’t verify application certificates against a central authority.

Self-signed certificates are commonly used.

Question 7

Importance of Keeping Signing Certificate Safe

Answer 7

Safeguarding the signing certificate is crucial.

Losing the certificate prevents issuing updates and may require publishing new applications.

Question 8

Inspecting Permissions

Answer 8

Applications need to request permissions for device access.

Users see abstracted permission information in the Play Store.

Permissions are defined in XML using <permission> and <uses-permission> tags.</uses-permission></permission>

Question 9

Finding Requested Permissions

Answer 9

Use the app.package.info module in drozer to find permissions for a specific app.

dz> run app.package.info -a com.android.browser.

Question 10

Search for Permissions

Answer 10

Use app.package.list with permission filtering.

dz> run app.package.list -p android.permission.READ_SMS.

Question 11

Permission Implications

Answer 11

Requesting permissions can add the app’s user identifier to a Linux group.

Some permissions are purely for access control, not groups.

Check /system/etc/permissions/platform.xml for permission mappings.

Question 12

Content Providers and Permissions

Answer 12

Content providers require permissions for access.

Android checks if an app has the required permission before granting access.

Query content providers to see which permissions are needed.

Question 13

Common Malware Tactics

Answer 13

Most Android malware relies on users not reading permissions.

They request permissions to access sensitive data.

No technical security flaw; exploits lack of user awareness.

Some malware bypasses security using kernel exploits for root access.

Signature-based protection restricts inter-app access.

Question 14

Protection Levels

Answer 14

Permissions have associated protection levels.

Levels determine conditions for permission requests.

Differentiate between normal, dangerous, signature, and system levels.

Correct protection level selection is crucial for security.

Question 15

normal - Protection Level

Answer 15

Default value.

0x0

Any app may request a permission with this protection level.

Question 16

dangerous - Protection Level

Answer 16

Indicates that this permission has the ability to access some potentially sensitive information or perform actions on the device.

0x1

Any application may request a permission with this protection level.

Question 17

signature - Protection Level

Answer 17

Indicates that this permission can only be granted to another application that was signed with the same certificate as the application that defined the permission.

0x2

Question 18

signatureOrSystem - Protection Level

Answer 18

This is the same as the signature protection level, except that the permission can also be granted to an application that came with the Android system image or any other application that is installed on the /system partition.

0x3

Question 19

system - Protection Level

Answer 19

This permission can only be granted to an application that came with the Android system image or any other application that is installed in particular folders on the /system partition.

0x10

Question 20

development - Protection Level

Answer 20

This permission can be granted from a privileged context to an application at runtime.

0x20

Question 21

Android Application Sandbox

Answer 21

Measures to prevent one app from harming others or accessing their data without permission.

Apps run as separate users in a Unix-like security model.

Private data directories are protected with user-specific file permissions.

Example: drwxr-x–x u0_a59 u0_a59 2014-05-11 18:49 com.mwr.dz.

World-executable directories can expose data if subfolders have lax permissions.

Question 22

SharedUserId Exception

Answer 22

Apps can share the same user identifier via android:sharedUserId in the manifest.

Granted only if signed with the same certificate.

Apps under the same UID share access, even with configurations to run in the same process.

Example: dz> run app.package.shareduid -u 10005.

Question 23

Binder and IPC Control

Answer 23

Binder is used for communication between apps.

Specialized IPC parcels check app permissions for tasks.

Android API calls to app components strictly enforce permissions.

Linux groups may enforce certain permissions instead of binder.

Question 24

Full Disk Encryption (FDE)

Answer 24

Encrypts the entire drive or volume.

Protects against lost or stolen disks.

Defeats common forensics techniques.

Question 25

FDE Implementation on Android

Answer 25

Uses dm-crypt in the kernel.

Encryption suite: aes-cbc-essiv:sha256.

Requires user activation before Android 5.0 (Lollipop).

Question 26

Key Derivation and User Password

Answer 26

User’s PIN/password encrypts FDE password.

Key derived from the user’s PIN/password.

KitKat onwards uses scrypt for stronger security.

Question 27

Data Encryption and SD Card Considerations

Answer 27

Encrypts the /data partition.

SD card encryption may vary among manufacturers.

Question 28

Protection and Limitations of FDE

Answer 28

Protects data at rest.

Transparent decryption during code execution.

Limits unauthorized access to stolen devices.