Secure developer options

Per the Android Compatibility Definition Document, OEMs must provide a way to enable app development. However, providing mobile-like developer options within cars leaves those cars vulnerable to attack. Access to developer options can now be gated by an OEM using an authenticated cryptographic token mechanism. Specifically, an OEM can:

  • Set desired default restrictions before the first boot.
  • Securely authorize developers, with crypto tokens if preferred.
  • Apply restriction changes once a developer is both authenticated and authorized.

This article describes a reference implementation consisting of a debugging restriction controller app and a remote token issuer endpoint.

Terminology

In addition to Terminology, these terms are used in this article:

  • JSON Web Signature (JWS), defined in RFC 7515
  • National Institute of Standards and Technology (NIST)

Design

OEMs can authorize developers with JSON Web Signature (JWS) tokens (RFC7515). In the reference implementation, access tokens are issued by OEMs and consumed by the restriction controller app. Access tokens are designed to resist replay attacks and forged tokens.

Figure 1. Design

Integration and configuration

OEMs must specify the desired default restrictions on the first boot. This is done with several static resource overlays to override the defaults in the AOSP framework.

The default restrictions for the headless system user can be configured with the config_defaultFirstUserRestrictions string in frameworks/base/core/res/res/values/config.xml, for example:

<!-- User restrictions set when the first user is created.
         Note: Also update appropriate overlay files. -->
    <string-array translatable="false" name="config_defaultFirstUserRestrictions">
        <item>no_debugging_features</item>
    </string-array>

The default restrictions for drivers, passengers, and guests can be configured in frameworks/base/core/res/res/xml/config_user_types.xml. An OEM can overlay| these strings to set the default restrictions on each type of user respectively, for example:

<user-types>
    <full-type name="android.os.usertype.full.SECONDARY" >
        <default-restrictions no_debugging_features="true"/>
    </full-type>
    <full-type name="android.os.usertype.full.GUEST" >
        <default-restrictions no_debugging_features="true"/>
    </full-type>
</user-types>

A reference implementation is provided at the following location in AOSP:

packages/apps/Car/DebuggingRestrictionController

Testing

Google recommends that OEMs start with the reference implementation and build out from there.

  1. After configuring the desired restrictions in the overlay files, compile AAOS and validate the defined flows. Use the reference app and local JWS enabled service to verify your access settings.
  2. Configure the system to use your JWS enabled cloud service (optional). Verify you're observing the desired flow on your backend service.