Android Platform #1: Android Architecture, Android Security

Shortcuts

---

What is Android?

Android System Architecture

• Hardware Abstraction Layer (HAL)
• Android Runtime (ART)

Android Users and Groups

Android Security

• I. Device Encryption
• II. Android Security
  • SELinux
  • ASLR, KASLR, PIE, DEP
  • SECCOMP

Reference

What is Android?

---

• Linux-based open source platform
• developed by Google
• mobile operating system(OS)
• consists pre-installed apps & third-party apps (install through Google Play store or what ever.)

Android System Architecture

---

Linux Kernel

• lowest level of Android system architecture

Hardware Abstraction Layer (HAL)

• locate on top of Linux kernel
• A layer that defines standard interface and allows OS interact with built-in hardware components.(devices)
• some HALs packaged into shared library module
  • when HAL required, Android system calls HAL.
• allowing applications to interact with the device's hardware.
  • ex) HAL allows stock application to use a device's microphone and speaker.

Android Runtime (ART)

Android Application

• writen in Java
• compiled to Dalvik bytecode : convert JVM bytecode to Dalvik bytecode which is .dex format.
• don't have direct access to hardware resources
• eache app runs its own sandbox
  • crashing app doesn't affect other app running on the device.

Android Runtime (ART)

• execute .dex format Dalvik bytecode on the Android Runtime (ART)
• difference with Dalvik Virtual Machine
  • Dalvik
    • Dalvik JVM(Java Virtual Machine)
    • JIT (just-in-time) compilation
      • bytecode is translated into machine code at execution time.
      • JIT compilation performed every time app is executed. → affects performance.
  • ART
    • current Android runtime
    • AOT(ahead-of-time) compilation
      • if apps execute for the first time, apps precompiled before execute.
      • precompiled machine code is used for all executions.
    • AOT compilation improves performance.
• controls maximum number of system resources allocated to apps
  • It prevents apps from monopolizing too many system resources

Android Users and Groups

---

• In Android, multi-user support of Linux Kernel is used to sandbox apps
• each app runs under a separate Linux user so that isolated from other apps and rest of the OS
• there are predefined users and groups in android_filesystem_config.h file
• UIDs for third-party applications added to list of users and groups in android_filesystem_config.h when installed

    #define AID_ROOT             0  /* traditional unix root user */
    #define AID_SYSTEM        1000  /* system server */
    #...
    #define AID_SHELL         2000  /* adb and debug shell user */
    #...
    #define AID_APP          10000  /* first app user */
    ...

Android Security

---

I. Device Encryption

• device encryption supports from Android 2.3.4 (API level 10), storage encryption from Android 6.0 (API level 23)

1. Full-Disk Encryption

• supported from Android 5.0 (API level 21)
• Full-Disk Encryption uses single key to protect user device password that used to encrypt and decrypt userdata part.
• drawback: not being able to receive calls, not having operative alarms after a reboot if user doesn't enter password to unlock
  • Therefore, File-Based Encryption should be used instead of Full-Disk Encryption.

2. File-Based Encryption

• supported from Android 7.0 (API level 24)
• File-Based Encryption allows different files encrypted with different keys - decipher independently
• support direct boot → direct boot enables the device to have access to features even if the user didn't unlock the device
  • feature such as alarms

3. Adiantum

• supported from Android 9 (API level 28), Linux kernel 5.0
• devices that use low-end processors, such as the ARM Cortex-A7 which don't have hardware accelerated AES(AES used for storage encryption).
• Adiantum is a cipher construction to fill the gap for set of devices which are not able to run AES at least at 50 MiB/s.
• Adiantum have operations: addtions, rotations, XORs
• Adiantum is secure as long as ChaCha12, AES-256.

II. Android Security

• mitigations to prevent applicatiom from vulnerabilities

SELinux

• a.k.a Security-Enhanced Linux
• SELinux uses a Mandatory Access Control (MAC) system to lock down which processes have access to which resources.
• MAC is applied to all processes including root, processes running super user permission
• user:role:type:mls_level label is given to each resource, which defines which users are able to execute which type of actions on that resource
• all exception trials are logged in dmesg, logcat by kernel

ASLR, KASLR, PIE, DEP

ASLR (Address Space Layout Randomization)

• since Android 4.1 (API level 15)
• standard protection against bufferoverflow attacks
• both application and OS are loaded to random memory address to make hard to get correct address for a specific memory region or library.

KASLR (Kernel Address Space Layout Randomization)

• since Android 8.0 (API level 26)
• memory address randomization for the kernel

PIE (Position Independent Executable)

• since Android 5.0 (API level 21)
• position independent executable on all range of binary

DEP (Data Execution Prevention)

• prevents code execution on the stack and heap
• prevents buffer-overflow exploits

SECCOMP

• a.k.a Secure Computing
• since Android 8 (API level 26)
• SECCOMP provide filters for all Zygote based processes so that it restrict the available syscalls used to exploit.

Reference

---

owasp-mstg github

Android Security:SELinux

Android Security:app sandbox