Opzioni sviluppatore sicure

Ai sensi del Compatibility Definition Document di Android, gli OEM devono fornire un modo per attivare lo sviluppo di app. Tuttavia, fornire opzioni sviluppatore simili a quelle per dispositivi mobili all'interno delle auto le rende vulnerabili agli attacchi. L'accesso alle opzioni sviluppatore ora può essere limitato da un OEM utilizzando un meccanismo di token crittografico autenticato. In particolare, un OEM può:

  • Specificare le limitazioni predefinite prima del primo avvio.
  • Autorizzare in modo sicuro gli sviluppatori, con token crittografici, se preferito.
  • Applicare le modifiche alle limitazioni una volta che uno sviluppatore è autenticato e autorizzato.

Questa pagina descrive un'implementazione di riferimento costituita da un'app di controllo delle limitazioni di debug e da un endpoint di emissione di token remoto.

Terminologia

Oltre a terminologia, in questa pagina vengono utilizzati i seguenti termini:

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

Design

Gli OEM possono autorizzare gli sviluppatori con token JSON Web Signature (JWS) (RFC7515). Nell'implementazione di riferimento, i token di accesso vengono emessi dagli OEM e utilizzati dall'app di controllo delle limitazioni. I token di accesso sono progettati per resistere agli attacchi di tipo replay e ai token falsificati.

Figura 1. Design

Integrazione e configurazione

Gli OEM devono specificare le limitazioni predefinite al primo avvio. Per farlo, utilizzano diversi overlay di risorse statiche per sostituire i valori predefiniti nel framework AOSP.

Le limitazioni predefinite per l'utente di sistema headless possono essere configurate con la stringa config_defaultFirstUserRestrictions in frameworks/base/core/res/res/values/config.xml, ad esempio:

<!-- 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>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</item>
    </string-array>

Le limitazioni predefinite per conducenti, passeggeri e ospiti possono essere configurate in frameworks/base/core/res/res/xml/config_user_types.xml. Un OEM può sovrapporre queste stringhe per impostare le limitazioni predefinite per ogni tipo di utente, ad esempio:

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

Controller delle preferenze del numero build

In AAOS, l'interazione dell'utente con la riga delle preferenze Numero build in Impostazioni viene gestita da BuildNumberPreferenceController.java che si trova in packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java.

Quando è impostata la limitazione utente no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES), BuildNumberPreferenceController sopprime il conto alla rovescia per gli sviluppatori nelle build di produzione (user) quando viene toccato:

@Override
protected boolean handlePreferenceClicked(Preference preference) {
    if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) {
        return true;
    }

    // Enforce restriction on production (user) builds
    if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) {
        showToast(R.string.dev_access_blocked_toast);
        return true;
    }

    mDevHitCountdown--;
    if (mDevHitCountdown == 0) {
        DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true);
        showToast(R.string.show_dev_on);
    }
    return true;
}

L'utilizzo di Build.IS_USER garantisce che le build di produzione applichino rigorosamente il blocco di sicurezza, mentre i team di progettazione interni nelle build userdebug possono comunque accedere alle opzioni sviluppatore utilizzando il gesto di 7 tocchi per i test senza sostituzioni manuali dell'interfaccia a riga di comando (CLI).

Controller delle limitazioni di debug

In AOSP è disponibile un'implementazione di riferimento del controller delle limitazioni di debug (DRC) all'indirizzo packages/apps/Car/DebuggingRestrictionController.

Il DRC consente agli OEM di eliminare in modo dinamico e temporaneo la limitazione no_debugging_features sui veicoli di produzione per i tecnici di assistenza e gli sviluppatori autorizzati. Invece di lasciare aperti in modo permanente gli strumenti di debug o di richiedere il reflash del firmware, l'app DRC nel veicolo chiede all'utente di autenticarsi con il backend OEM e di inviare un token di accesso firmato crittograficamente per abilitare adb e le opzioni sviluppatore per una sessione di diagnostica limitata.

L'implementazione di riferimento del DRC è costituita da due componenti principali:

  • App client DRC nel veicolo (app/): un'app di sistema con privilegi (con l'autorizzazione MANAGE_USERS) sull'unità principale che autentica gli sviluppatori, convalida la firma del certificato X.509, il nome host, il nonce e la scadenza dei token JWS in entrata e attiva/disattiva dinamicamente la limitazione no_debugging_features utilizzando UserManager.
  • Servizio di emissione di token cloud (server/): un servizio web di backend (implementabile come Funzioni cloud di Firebase) che autentica le credenziali dello sviluppatore ed emette token di accesso JWS RS256 firmati crittograficamente con una finestra di scadenza limitata.

Per istruzioni complete sulla configurazione, strumenti di generazione dei certificati e passaggi di deployment, consulta la guida all'integrazione del controller delle limitazioni di debug.

Test

Google consiglia agli OEM di iniziare con l'implementazione di riferimento e di svilupparla da lì.

  1. Dopo aver configurato le limitazioni nei file di overlay, compila AAOS e convalida i flussi definiti. Utilizza l'app di riferimento e il servizio locale abilitato per JWS per verificare le impostazioni di accesso.
  2. (Facoltativo) Configura il sistema in modo che utilizzi il tuo servizio cloud abilitato per JWS. Verifica che il flusso previsto sia presente nel servizio di backend.