Zabezpieczanie opcji programisty

Zgodnie z dokumentem definicji zgodności z Androidem producenci OEM muszą zapewnić możliwość tworzenia aplikacji. Jednak udostępnienie w samochodach opcji dla deweloperów podobnych do tych w telefonach czyni je podatnymi na ataki. Producent OEM może teraz ograniczyć dostęp do opcji dla deweloperów za pomocą uwierzytelnionego mechanizmu tokena kryptograficznego. W szczególności producent OEM może:

  • Przed pierwszym uruchomieniem ustaw odpowiednie domyślne ograniczenia.
  • bezpiecznie autoryzować deweloperów, np. za pomocą tokenów kryptograficznych;
  • Zmiany ograniczeń są stosowane, gdy deweloper zostanie uwierzytelniony i upoważniony.

Z tego artykułu dowiesz się, jak zaimplementować rozwiązanie referencyjne, które składa się z aplikacji do debugowania ograniczeń i usług zdalnego punktu końcowego emitenta tokenów.

Terminologia

Oprócz terminologii w tym artykule używamy tych terminów:

  • Podpis internetowy JSON (JWS) zdefiniowany w RFC 7515
  • Narodowy Instytut Standaryzacji i Technologii (NIST)

Projektowanie

Producenci urządzeń OEM mogą autoryzować programistów za pomocą tokenów podpisu internetowego JSON (JWS) (RFC7515). W implementacji referencyjnej tokeny dostępu są wydawane przez producentów urządzeń i używane przez aplikację kontrolera ograniczeń. Tokeny dostępu są zaprojektowane tak, aby chronić przed atakami polegającymi na odtwarzaniu i podrabianiu tokenów.

Rysunek 1. Projektowanie

Integracja i konfiguracja

Producenci OEM muszą określić domyślne ograniczenia podczas pierwszego uruchomienia. Wykorzystuje ono kilka nakładek statycznych zasobów, aby zastąpić domyślne wartości w ramach AOSP.

Domyślne ograniczenia dla użytkownika systemu bez interfejsu graficznego można skonfigurować za pomocą ciągu znaków config_defaultFirstUserRestrictions w pliku 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 dotyczące kierowców, pasażerów i gości można skonfigurować w frameworks/base/core/res/res/xml/config_user_types.xml. Producent OEM może nakładać te ciągi znaków, aby odpowiednio ustawić domyślne ograniczenia dla poszczególnych typów użytkowników, 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 AOSP w tej lokalizacji:

packages/apps/Car/DebuggingRestrictionController

Testowanie

Google zaleca, aby OEM zaczęli od implementacji referencyjnej i na jej podstawie opracowali własne rozwiązania.

  1. Po skonfigurowaniu odpowiednich ograniczeń w plikach nakładki skompiluj AAOS i zweryfikuj zdefiniowane przepływy. Aby sprawdzić ustawienia dostępu, użyj aplikacji referencyjnej i lokalnej usługi obsługującej JWS.
  2. Skonfiguruj system tak, aby używał usługi w chmurze z włączoną obsługą JWS (opcjonalnie). Sprawdź, czy obserwujesz prawidłowy przepływ danych w usłudze backendowej.