Zabezpieczenie opcji deweloperskich

Zgodnie z dokumentem definicji zgodności systemu Android producenci OEM muszą zapewnić sposób umożliwiający tworzenie aplikacji. Jednak zapewnienie w samochodach opcji programistycznych przypominających urządzenia mobilne naraża te samochody na ataki. Dostęp do opcji programistycznych może teraz być blokowany przez producenta OEM przy użyciu uwierzytelnionego mechanizmu tokena kryptograficznego. W szczególności producent OEM może:

  • Ustaw żądane domyślne ograniczenia przed pierwszym uruchomieniem.
  • Bezpiecznie autoryzuj programistów za pomocą tokenów kryptograficznych, jeśli jest to preferowane.
  • Zastosuj zmiany ograniczeń, gdy programista zostanie zarówno uwierzytelniony, jak i autoryzowany.

W tym artykule opisano implementację referencyjną składającą się z aplikacji kontrolera ograniczeń debugowania i punktu końcowego wystawcy tokenu zdalnego.

Terminologia

Oprócz terminologii w tym artykule zastosowano następujące terminy:

  • Podpis sieciowy JSON (JWS), zdefiniowany w dokumencie RFC 7515
  • Narodowy Instytut Standardów i Technologii (NIST)

Projekt

Producenci OEM mogą autoryzować programistów za pomocą tokenów JSON Web Signature (JWS) (RFC7515). W implementacji referencyjnej tokeny dostępu są wydawane przez producentów OEM i wykorzystywane przez aplikację kontrolera ograniczeń. Tokeny dostępu zaprojektowano tak, aby były odporne na ataki polegające na powtarzaniu i sfałszowane tokeny.

Rysunek 1. Projekt

Integracja i konfiguracja

Producenci OEM muszą określić żądane domyślne ograniczenia przy pierwszym uruchomieniu. Odbywa się to za pomocą kilku statycznych nakładek zasobów, które zastępują ustawienia domyślne w środowisku AOSP.

Domyślne ograniczenia dla bezgłowego użytkownika systemu można skonfigurować za pomocą ciągu config_defaultFirstUserRestrictions w frameworks/base/core/res/res/values/config.xml , na przykład:

<!-- 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>

Domyślne ograniczenia dla kierowców, pasażerów i gości można skonfigurować w frameworks/base/core/res/res/xml/config_user_types.xml . OEM może nakładać | te ciągi, aby ustawić domyślne ograniczenia odpowiednio dla każdego typu użytkownika, na przykład:

<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>

Implementacja referencyjna jest dostępna w następującej lokalizacji w AOSP:

packages/apps/Car/DebuggingRestrictionController

Testowanie

Google zaleca, aby producenci OEM rozpoczęli od implementacji referencyjnej i na tej podstawie rozwijali swoje rozwiązania.

  1. Po skonfigurowaniu żądanych ograniczeń w plikach nakładek skompiluj AAOS i zatwierdź zdefiniowane przepływy. Użyj aplikacji referencyjnej i lokalnej usługi obsługującej JWS, aby zweryfikować ustawienia dostępu.
  2. Skonfiguruj system do korzystania z usługi w chmurze obsługującej JWS (opcjonalnie). Sprawdź, czy obserwujesz pożądany przepływ w usłudze zaplecza.