Attributes

We collect data for the following attributes:

  • Latest Security Patch Level [date]: The latest security update date seen for specific devices shows the current software security state of a device. These updates are announced and described in the Android Security Bulletins. Security patches are usually divided into open-source and closed-source parts and they include Android platform fixes in AOSP, upstream Linux kernel fixes and fixes of SOC components.
  • Average Patch Frequency [days]: The average duration between receiving security updates is an indication for how long a device may run with an open security issue in standard cases. Within the lifetime of an Android device it is expected that the patch frequency gradually decreases until it reaches its End of Life (EOL) notice. Patch frequencies can be divided into four update periods: monthly, bi-monthly, quarterly and biannual. Note that often the release of security updates is coordinated with the public release of details on discovered security issues, but that this measure does not correlate the public disclosure of a vulnerability with the release of the related security fix.*
  • Guaranteed Maximum Patch Delay [days]: The maximum duration between receiving security updates promised by the device manufacturer through device update policies published at (or after) product release is an indication for how long a device may run with open security issues in the worst case. Some manufacturers define “regular” security update periods which we assume to be biannual updates. As of November 2023 following manufacturers release a list of devices with defined update schedules:
    • Huawei distinguishes monthly and quarterly security updates.
    • Motorola distinguishes monthly, bi-monthly and biannual security updates.
    • Nokia distinguishes monthly and quarterly security updates.
    • OnePlus only publishes a list of flagship devices with monthly security updates.
    • Oppo distinguishes monthly and quarterly security updates.
    • Samsung distinguishes monthly, quarterly and biannual security updates.
    • Vivo distinguishes monthly, quarterly and biannual security updates.
  • Guaranteed Patch Availability [years]: The minimum duration for which security updates are made available after initial product launch promised by the device manufacturer is an indication for how long a device can be used securely after it has been bought. Note that most manufacturers guarantee availability of security patches for a duration starting with the initial launch of the product, and not necessarily from the date it has been purchased.
  • Published End of Life Notices [date]: The date at which security patches end for a specific device as published by the device manufacturer can be used for planning appropriate actions after that device is no longer supported. Note that this date is typically equal to or after the date of initial product launch + guaranteed patch availability (which is often a generic guarantee, while this metric may be published for specific devices).
  • Latest Android release [API number]: The version number of the latest Android release. Newer Android releases generally add security mitigations and are typically preferrable for better security. Orthogonally of the latest security patch level.
  • Multi-user Support [boolean]: True if a device supports switching between multiple Android users. This can be used to separate data of multiple people using the same shared (e.g. family or organizational) device or to separate between different tasks/contexts of a single user, and is therefore beneficial for securing data.
  • A/B System Updates [boolean]: True if system updates can be downloaded and applied in the background, to be activated automatically upon next reboot. This decreases the user-visible time to apply an update during which a device is non-functional, and therefore increases the probaility that users will quickly apply available system updates. While it does not make a difference to users who always apply updates explicitly, on average and over a large population, this typically increases apply rate of updates.
  • Face Authentication [boolean]: True if the device hardware supports the face authentication method. Biometric authentication methods are rated with the three metrics Spoof Acceptance Rate (SAR), Imposter Acceptance Rate (IAR), and False Acceptance Rate (FAR) and classified into three classes based on the results.
  • Fingerprint Authentication [boolean]: True if the device hardware supports the fingerprint authentication method. Biometric authentication methods are rated with the three metrics Spoof Acceptance Rate (SAR), Imposter Acceptance Rate (IAR), and False Acceptance Rate (FAR) and classified into three classes based on the results.
  • Iris Authentication [boolean]: True if the device hardware supports the iris authentication method. Biometric authentication methods are rated with the three metrics Spoof Acceptance Rate (SAR), Imposter Acceptance Rate (IAR), and False Acceptance Rate (FAR) and classified into three classes based on the results.
  • Key Attestation Unique ID [boolean]: True if the UNIQUE_ID is returned by the Keymaster when the INCLUDE_UNIQUE_ID is NOT used during key generation. This attribute is expected to be false.
  • Trusted Execution Environment [boolean]: True if the device supports Trusted Execution Environment (TEE) hardware-backed keystore to hold cryptographic keys in an dedicated environment.
  • Strongbox Support [boolean]: True if the device support Keymaster Strongbox to hold cryptographic keys in dedicated secure, tamper resistant hardware (such as a secure element chip). This increases security of cryptographic key material stored within Strongbox by reducing attack surface of the Keymaster implementation.
  • Keymaster Version [number]: The latest supported Keymaster | KeyMint version of the system. The Keymaster | KeyMint version defines the available functions of the hardware-backed keystore. Modern smartphones either support Trusted Execution Environment (TEE) or the Strongbox approach.
  • Keystore Case Sensitive [boolean]: True if the Keymaster successfully differentiated case sensitive key names.
  • Keystore Export [boolean]: True if keys can be extracted from the Keymaster. This attribute is expected to be false.
  • Keystore Import [boolean]: True if keys can be imported into the Keymaster.
  • Bluetooth [list of supported versions]: A list of supported Bluetooth versions, profiles and codecs of the device.
  • Embedded Secure Element (eSE) [boolean]: True if the device has an embedded Secure Element which is dedicated, separate tamper-resistant hardware to store cryptographic data.
  • Embedded SIM (eSIM) [boolean]: True if the device hardware supports embedded SIM functionality.
  • SD [boolean]: True if a SD card slot is available on the device.
  • Universal Integrated Circuit Card (UICC) [number]: Number of installed Universal Integrated Circuit Cards (UICC).
  • Open Mobile API eSE, smartSD, UICC [number of units]: Open Mobile API is a standard API which communicates with the Secure Element. These attributes count the number of Secure Elements, SD Card Slots and Universal Integrated Circuit Card Slots.
  • NFC [boolean]: True if the device supports the NFC technology.
  • Android Virtualization Framework [boolean]: Google included the Android Virtualization Framework (AVF) in Android 13 to provide the possibility of running so-called protected VMs (pVM ) on Android devices. These pVMs must be signed by Google or device vendors. True if AVF is supported.
  • Enhanced RO File System (EROFS) [boolean]: EROFS is a read-only file system initially developed by Huawei. It is optimized for performance and helps to reduce the space needed for OTA firmware images. All devices launched with Android 13 or higher must support EROFS. True if EROFS is supported.
  • Identity Credential [boolean]: Android Devices with Android 11 and higher support Identity Credentials which can be used to securely store and use digital documents like the mobile driver licence (mDL). True if the device supports Identity Credentials.
  • Protected Confirmation [boolean]: True if Protected Confirmation is supported by the device. Protected Confirmation supports applications to initiate sensitive transactions such as payments and is deployed on supported devices since Android 9. When used the app displays a confirmation prompt asking the user to affirm.
  • Zero Touch [boolean]: True if Zero Touch is supported by the device. Zero Touch devices allow central management of devices in enterprises.
  • Encrypted Shared Preferences [boolean]: True if Encrypted Shared Preferences work as expected. This means that stored Encrypted Shared Preferences can be successfully read after reopening an app.
  • Trusted Certificate Authorities [min | max | median | mean]: Number of trusted CAs in the system - either [min | max | median | mean] or [min] if all measurements are equal.
  • Settings Enabled/Disabled [boolean]: Interesting settings for statistical evaluation of the security of a device. Multiple Users Activated, Adb Enabled, Developer Options Enabled, Rooted, Verified Boot, etc.

When possible, we try to map those attributes to related definitions such as those in ETSI TS 103 645 or by the Internet of Secure Things Alliance (both of which are focused on IoT devices, but the the definitions can apply to mobile phone security as well).

The average patch frequency and guaranteed patch availability / published end of security patches can be seen as specific metrics e.g. for ETSI TS 103 645 Provision 4.3-3 and 4.3-4, respectively. Future collected attributes may also map to other such standard provisions. However, this project also aims to collect and analyze metrics that do not yet map to a specific security target, but support explorative analysis of device security postures.