Bezpieczne opcje dla programistów

Zgodnie z dokumentem z definicją zgodności z Androidem. OEM musi umożliwiać tworzenie aplikacji. Jednak udostępnianie materiałów w stylu mobilnym opcji programistycznych w samochodach sprawia, że te samochody są narażone na atak. Dostęp do programisty opcje zabezpieczeń mogą być teraz zabezpieczane przez OEM za pomocą uwierzytelnionego mechanizmu tokena kryptograficznego. W szczególności OEM może:

  • Ustaw wymagane ograniczenia domyślne przed pierwszym uruchomieniem.
  • Bezpiecznie autoryzuj deweloperów przy użyciu tokenów kryptograficznych (jeśli wolisz).
  • Zastosuj zmiany ograniczeń, gdy deweloper zostanie uwierzytelniony i autoryzowany.

W tym artykule opisano referencyjną implementację obejmującą ograniczenie debugowania aplikacji kontrolera i punktu końcowego wydawcy tokena.

Terminologia

Oprócz terminów terminologii W tym artykule użyto następujących terminów:

  • Podpis internetowy JSON (JWS) zdefiniowany w RFC 7515
  • Narodowy Instytut Standardów i Technologii (National Institute of Standards and Technology, NIST)

Projektowanie

OEM może autoryzować programistów za pomocą tokenów JSON Web Signature (JWS) (RFC7515). W implementacji referencyjnej, tokeny dostępu są wydawane przez OEM i wykorzystywane w ramach ograniczeń w aplikacji kontrolera. Tokeny dostępu mają za zadanie odpierać ataki typu replay i sfałszowane tokeny.

Rysunek 1. Projektowanie

Integracja i konfiguracja

OEM musi określić żądane ograniczenia domyślne przy pierwszym uruchomieniu. Odbywa się to za pomocą kilka statycznych nakładek zasobów, które zastępują wartości domyślne w platformie AOSP.

Domyślne ograniczenia dla użytkownika systemu bez interfejsu graficznego można skonfigurować za pomocą Ciąg tekstowy 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 tym miejscu w AOSP:

packages/apps/Car/DebuggingRestrictionController

Testowanie

Google zaleca producentom OEM, aby zaczynali od implementacji referencyjnej i rozwijali ją.

  1. Po skonfigurowaniu odpowiednich ograniczeń w plikach nakładek skompiluj AAOS i weryfikacji zdefiniowanych przepływów. Użyj aplikacji referencyjnej i lokalnej usługi obsługującej JWS aby sprawdzić ustawienia dostępu.
  2. Skonfiguruj system tak, aby używał usługi w chmurze obsługującej JWS (opcjonalnie). Potwierdź, że jesteś i zauważenie pożądanego przepływu w usłudze backendu.