ASM CH1 - The context and basis of ASM 

1
This blog is a comprehensive review of the paper  [Android Security Model](https://arxiv.org/pdf/1904.05572), based on the content ot the paper, some personal thoughts are also added to this blog including the personal perspective of the author to ASM and the summarization of the content and so on.

1.1 Android is an opensource ecosystem

In real world, OEM (Original Equipment
Manufacturers) manufactures the products we use such as smartphone, watch and so on. Some of the OEMs aren’t capable of developing the Android components by themselves, so they rely on ODM(Original Device Manufacturers) who’s for hardware and firmware developing, and they are able to modify the Android componets. 

1
2
3
4
5
6
7
Definition of OEM, ODM and OBM:

OEM is the abbreviation of Original Equipment Manufacturer, that is, the factory produces products according to the requirements of the brand manufacturer, including technology, key equipment, etc. are all provided by the brand manufacturer. For example, Foxconn is the OEM model for Apple;

ODM is the abbreviation of Original Design Manufacturer. Generally, ODM has original design capabilities and can provide one-stop services from design to assembly of mobile phones according to the requirements/definition of the brand. The profit will be higher than OEM and the autonomy is also higher;

OBM is the abbreviation of Original Brand Manufacturer. OBM factories have their own brands, can develop new products, produce and sell new products by themselves. Among the current mobile phone giants, Huawei has begun to use the OBM model more;

Due to this objective situation, AOSP (Android Open Source Program) provides reference implementation for nearly all components (Linux kernel, Trusty, libavb etc.) so that the manufacture can decide which implementation to use based on their requirements.

Two objective facts:

  1. For users, android treats them as someone with no ideas of any technical knowledge about the system.
  2. For developers, android provides them with maximum development flexibility, so
    • Explicitly supports installation of apps from arbitrary sources, including alternative app stores and apps independently distributed without a store at all.
    • Allows applications to be written in any programming language, with or without runtime support, compiled or interpreted.

1.2 Android is defined by compatibility requirements

Android Compatibility Talbe

1
2
3
4
5
6
7
8
9
10
In fact, the Android platform is defined as the set of AOSP components that together form an operating system that adheres to standards called the Compatibility Definition Document (CDD).

AOSP provides a series of tests, including the Compatibility Test Suite (CTS), which allow a device manufacturer to test if their system complies with the CDD.

It may be the case that a system that passes CTS does not follow the CDD, for example the CDD is a “whole device standard,” so a virtual machine or emulator running AOSP might pass CTS, but still not follow the CDD.

Devices that do not conform to the CDD (and/or do not pass CTS), by definition, are not Android.
Further, devices that advertise themselves as Android as a trademarked name need to, at minimum, pass CTS and an additional set of tests called the Vendor Test Suite (VTS).

Finally, Android devices are subjected to additional requirements to be certified to run Google Mobile Services, which we call GMS Android. Though devices based purely on AOSP are only required to ensure that they meet publicly documented compatibility tests, those shipping with Google services are held to a stricter standard, including additional compliance tests focusing on security and privacy

With so many kinds of so-called “androids” system existing, the threat model given in this blog only supports those adhere to CDD&CTS.

1.3 Threat model

There are mainly 4 types of assumed threat models for Android, they are based on the facts that Adversaries can get physical access to Android devices, Network communication is untrusted, Untrusted code is executed on the device and Untrusted content is processed by the device.

  1. Threats due to physical or proximal(P) access:

    Level Description
    T.P1 Adversary has the access to the device (proximal control), they control some of the ways including WiFi, Bluetooth, UWB, FM and so on of the device
    T.P2 Powered-off devices under complete physical control of an adversary (nation state wise attack)
    T.P3 Screen locked devices under complete physical control of an adversary (thieves)
    T.P4 Screen unlocked (shared) devices under control of an authorized but different user (your wife trying to find out your possibly existing messages with other women)

  2. network-level(N) threats:

    Level Description
    T.N1 Passive eavesdropping and traffic analysis, based on MAC address or other device network identifiers
    T.N2 Active manipulation of network traffic (Man-in-the-middle attack, on-path attack or relaying)
    T.N3 Adversarial cellular network provider (fake cellular base station)

  3. Threats due to installation of application(A) code from arbitrary sources:

    Level Description
    T.A1 Abusing APIs supported by the OS with malicious intent, e.g. spyware
    T.A2 Abusing APIs provided by other apps installed on the device
    T.A3 Untrusted code from the web is executed without explicit authorization
    T.A4 Mimicking system or other app user interfaces to confuse users (phishing)
    T.A5 Reading content from system or other app user interfaces
    T.A6 Injecting input events into system or other app user interfaces
    T.A7 Exploiting bugs in the OS to escalate privileges or gain code execution
    T.A8 Surreptitiously adding potentially harmful code to system images or other code or data executed or interpreted on-device through insider capabilities such as access to private code signing keys

  4. Treats from the processing of data(D) and metadata:

    Level Description
    T.D1 Abusing unique identifiers for targeted attacks (spamming or fake official email)
    T.D2 Exploiting code that processes untrusted content in the OS, firmware, or apps

  5. Supply chain attack vectors

  6. Insider attacks

Need to attention that the threat model of “nation state” or “organizational attacks” are not well defined here (since it’s pretty hard to sort out the factors of them), but it’s necessary to take them as part of the realistic threat model.