Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Sprawdzaj pary kluczy wspieranych sprzętowo za pomocą atestu kluczy

Atestacja klucza daje większą pewność, że klucze używane w aplikacji są przechowywane w sprzętowym magazynie kluczy urządzenia. W kolejnych sekcjach opisujemy, jak sprawdzić właściwości kluczy sprzętowych i jak interpretować dane rozszerzenia certyfikatów atestacji.

Zanim zaczniesz: upewnij się, że Twoje urządzenie obsługuje atestację klucza na poziomie sprzętowym

Zanim sprawdzisz właściwości kluczy sprzętowych urządzenia w środowisku produkcyjnym, upewnij się, że urządzenie obsługuje atestację klucza na poziomie sprzętowym. Aby to zrobić, sprawdź, czy łańcuch certyfikatów atestacji zawiera certyfikat główny podpisany kluczem głównym atestacji Google oraz czy element attestationSecurityLevel w strukturze danych opisu klucza jest ustawiony na poziom bezpieczeństwa TrustedEnvironment lub na poziom bezpieczeństwa StrongBox.

Dodatkowo ważne jest, aby sprawdzić podpisy w łańcuchu certyfikatów i potwierdzić, że żaden z kluczy w łańcuchu nie został unieważniony. W tym celu sprawdź listę stanu unieważnienia certyfikatów. Jeśli wszystkie certyfikaty nie są prawidłowe, a certyfikat główny nie jest kluczem głównym Google, nie ufaj w pełni atestacji.

Pobieranie i weryfikowanie pary kluczy sprzętowych

Podczas atestacji klucza określasz alias pary kluczy i pobierasz jej łańcuch certyfikatów, którego możesz użyć do sprawdzenia właściwości tej pary kluczy.

Jeśli urządzenie obsługuje atestację klucza na poziomie sprzętowym, certyfikat główny w tym łańcuchu jest podpisany kluczem głównym atestacji, który jest bezpiecznie udostępniany w sprzętowym magazynie kluczy urządzenia.

Aby zaimplementować atestację klucza, wykonaj te czynności:

Użyj metody obiektu KeyStore getCertificateChain() , aby uzyskać odniesienie do łańcucha certyfikatów X.509 powiązanych ze sprzętowym magazynem kluczy.
Wyślij certyfikaty na oddzielny serwer, któremu ufasz, aby przeprowadzić weryfikację.

Uwaga: nie wykonuj poniższego procesu weryfikacji na tym samym urządzeniu. Jeśli system Android na tym urządzeniu zostanie naruszony, proces weryfikacji może uznać za zaufane coś, co nie jest zaufane.
Uzyskaj odniesienie do biblioteki analizy i weryfikacji łańcucha certyfikatów X.509 która najlepiej pasuje do Twojego zestawu narzędzi. Sprawdź, czy główny certyfikat publiczny jest zaufany i czy każdy certyfikat podpisuje następny certyfikat w łańcuchu.
Sprawdź stan unieważnienia każdego certyfikatu , aby upewnić się, że żaden z nich nie został unieważniony.
Opcjonalnie możesz sprawdzić rozszerzenie certyfikatu informacji o udostępnianiu, które jest dostępne tylko w nowszych łańcuchach certyfikatów.

Uzyskaj odniesienie do biblioteki parsera CBOR, która najlepiej pasuje do Twojego zestawu narzędzi. Znajdź najbliższy certyfikat główny, który zawiera rozszerzenie certyfikatu informacji o udostępnianiu. Użyj parsera, aby wyodrębnić z tego certyfikatu dane rozszerzenia certyfikatu informacji o udostępnianiu.

Więcej informacji znajdziesz w sekcji dotyczącej rozszerzenia informacji o udostępnianiu.
Uzyskaj odniesienie do biblioteki parsera ASN.1, która najlepiej pasuje do Twojego zestawu narzędzi. Znajdź najbliższy certyfikat główny, który zawiera rozszerzenie certyfikatu atestacji klucza. Jeśli rozszerzenie certyfikatu informacji o udostępnianiu było obecne, rozszerzenie certyfikatu atestacji klucza musi znajdować się w bezpośrednio następującym certyfikacie. Użyj parsera, aby wyodrębnić z tego certyfikatu dane rozszerzenia certyfikatu atestacji klucza.

Uwaga: nie zakładaj, że rozszerzenie certyfikatu atestacji klucza znajduje się w certyfikacie liścia łańcucha. Możesz ufać tylko pierwszemu wystąpieniu rozszerzenia w łańcuchu. Wszystkie kolejne wystąpienia rozszerzenia nie zostały wydane przez bezpieczny sprzęt i mogły zostać wydane przez atakującego, który rozszerzył łańcuch podczas próby utworzenia fałszywych atestów dla niezaufanych kluczy.

Próbka atestacji klucza używa parsera ASN.1 z biblioteki Bouncy Castle do wyodrębniania danych rozszerzenia certyfikatu atestacji. Możesz użyć tej próbki jako odniesienia do utworzenia własnego parsera.

Więcej informacji znajdziesz w sekcji dotyczącej schematu danych rozszerzenia atestacji klucza.
Sprawdź, czy dane rozszerzenia pobrane w poprzednich krokach są spójne, i porównaj je z zestawem wartości, które powinien zawierać klucz sprzętowy.

Certyfikaty główne

Wiarygodność atestacji zależy od certyfikatu głównego łańcucha. Urządzenia z Androidem , które przeszły testy wymagane do korzystania z pakietu aplikacji Google, w tym z Google Play, i które zostały wprowadzone na rynek z Androidem 7.0 (poziom interfejsu API 24) lub nowszym, powinny używać kluczy atestacji podpisanych certyfikatem głównym atestacji sprzętu Google. Pamiętaj, że atestacja nie była wymagana do Androida 8.0 (poziom interfejsu API 26). Zestaw prawidłowych certyfikatów głównych można pobrać jako a tablicę w formacie JSON.

Certyfikaty główne

Podczas weryfikacji łańcucha certyfikatów atestacji klucza należy używać tych 2 certyfikatów głównych jako kotwic zaufania.

Wcześniej wydane certyfikaty główne

Jeśli certyfikat główny w otrzymanym łańcuchu atestacji zawiera ten klucz publiczny i żaden z certyfikatów w łańcuchu nie został unieważniony, oznacza to, że:

Twój klucz znajduje się w sprzęcie, który Google uważa za bezpieczny;
ma właściwości opisane w certyfikacie atestacji.

Jeśli łańcuch atestacji ma inny główny klucz publiczny, Google nie gwarantuje bezpieczeństwa sprzętu. Nie oznacza to, że Twój klucz został naruszony, tylko że atestacja nie potwierdza, że klucz znajduje się w bezpiecznym sprzęcie. Dostosuj do tego swoje założenia dotyczące bezpieczeństwa.

Jeśli certyfikat główny nie zawiera klucza publicznego na tej stronie, prawdopodobnie są 2 przyczyny:

Najprawdopodobniej urządzenie zostało wprowadzone na rynek z Androidem w wersji starszej niż 7.0 i nie obsługuje atestacji sprzętu. W takim przypadku Android ma implementację atestacji w oprogramowaniu, która generuje ten sam rodzaj certyfikatu atestacji, ale podpisany kluczem zakodowanym na stałe w kodzie źródłowym Androida. Ponieważ ten klucz podpisywania nie jest tajny, atestacja mogła zostać utworzona przez atakującego, który udaje, że zapewnia bezpieczny sprzęt.
Drugi prawdopodobny powód to fakt, że urządzenie nie jest urządzeniem Google Play. W takim przypadku producent urządzenia może utworzyć własny certyfikat główny i zdefiniować znaczenie danych atestacji. Zapoznaj się z dokumentacją producenta urządzenia. Pamiętaj, że Google nie wie o żadnym producencie urządzenia, który by to zrobił.

Wycofywanie kluczy fabrycznych: zdalne udostępnianie kluczy (RKP)

W przypadku urządzeń wprowadzanych na rynek z Androidem 16 system obsługuje tylko RKP. Ta zasada wycofuje klucze fabryczne. Ulepsza sposób udostępniania kluczy atestacji i zarządzania nimi, rozszerzając zasadę Androida 15, w której obsługa RKP była opcjonalna. RKP zapobiega wyciekowi kluczy, ponieważ system nie programuje kluczy bezpośrednio na urządzeniu. Nie możesz usunąć tych kluczy z urządzenia. Jeśli musisz unieważnić klucz, możesz skierować unieważnienie na jedno urządzenie.

Biblioteki weryfikacji atestacji

Do weryfikacji łańcuchów certyfikatów atestacji klucza użyj biblioteki Kotlin do weryfikacji atestacji. Jeśli używasz innego weryfikatora, zalecamy przejście na bibliotekę Kotlin. Jest ona dobrze przetestowana i obejmuje przypadki brzegowe, które często są pomijane przez niestandardowe weryfikatory.

Lista stanu unieważnienia certyfikatów

Klucze atestacji mogą zostać unieważnione z różnych powodów, m.in. z powodu nieprawidłowego obchodzenia się z nimi lub podejrzenia, że zostały wyodrębnione przez atakującego. Dlatego ważne jest, aby stan każdego certyfikatu w łańcuchu atestacji był sprawdzany na podstawie oficjalnej listy stanu unieważnienia certyfikatów (CRL). Ta lista jest utrzymywana przez Google i publikowana pod adresem: https://android.googleapis.com/attestation/status. Nagłówek Cache-Control w odpowiedzi HTTP określa, jak często należy sprawdzać dostępność aktualizacji, dzięki czemu nie jest wymagane wysyłanie żądania sieciowego w przypadku każdego weryfikowanego certyfikatu. Ten adres URL zwraca plik JSON zawierający stan unieważnienia wszystkich certyfikatów, które nie mają normalnego stanu ważności. Format pliku JSON jest zgodny z tą definicją roboczą schematu JSON 07:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "entries": {
      "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
      "type": "object",
      "propertyNames": {
        "pattern": "^[a-f1-9][a-f0-9]*$"
      },
      "additionalProperties": {
        "type": "object",
        "properties": {
          "status": {
            "description": "[REQUIRED] Current status of the key.",
            "type": "string",
            "enum": ["REVOKED", "SUSPENDED"]
          },
          "expires": {
            "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
            "type": "string",
            "format": "date"
          },
          "reason": {
            "description": "[OPTIONAL] Reason for the current status.",
            "type": "string",
            "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
          },
          "comment": {
            "description": "[OPTIONAL] Free form comment about the key status.",
            "type": "string",
            "maxLength": 140
          }
        },
        "required": ["status"],
        "additionalProperties": false
      }
    }
  },
  "required": ["entries"],
  "additionalProperties": false
}

Przykład listy CRL:

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

Wygasłe klucze fabryczne: nadal zaufane

Urządzenia wprowadzone na rynek przed 2021 r. mają klucze atestacji z wygasłymi certyfikatami. Te klucze są nadal zaufane, chyba że znajdują się na liście unieważnionych certyfikatów. Zalecamy, aby nadal ufać certyfikatom, które są powiązane z certyfikatem głównym z podmiotem SERIALNUMBER=f92009e853b6b045, niezależnie od okresu ważności certyfikatu. Ważne jest jednak, aby okres ważności certyfikatów zdalnego udostępniania kluczy (RKP) był nadal sprawdzany. Krótszy okres ważności certyfikatów RKP jest ważnym elementem modelu zagrożeń i ma na celu umożliwienie szybszego reagowania na naruszenia. Biblioteka Kotlin do atestacji klucza weryfikacji prawidłowo obsługuje wygaśnięcie we wszystkich przypadkach.

Zasady unieważniania certyfikatów

Atestacja jest podstawą przeciwdziałania nadużyciom i zaufania w ekosystemie Androida. Zapewnia ona stronom zewnętrznym, które nie mają dostępu do urządzenia, kryptograficznie weryfikowalny komunikat o stanie uruchomienia urządzenia.

Certyfikaty kluczy atestacji Androida zostaną unieważnione, gdy klucze zostaną naruszone, ze względu na krytyczny charakter ważności atestacji. W tej sekcji przedstawiamy zasady dotyczące unieważniania certyfikatów. Zasady te mogą się zmieniać i z czasem mogą obejmować dodatkowe przypadki.

Co kwalifikuje się do unieważnienia?

Klucze atestacji, które wyciekły, zawsze kwalifikują się do unieważnienia certyfikatów. Wycieki można wykryć na kilka sposobów, m.in.:

analiza danych atestacji w środowisku produkcyjnym;
wykrycie kluczy atestacji w mediach społecznościowych lub innych witrynach publicznych;
raporty bezpośrednio od badaczy bezpieczeństwa.

Po wykryciu certyfikaty atestacji zostaną unieważnione przez dodanie ich numerów seryjnych do listy unieważnionych certyfikatów. Zwykle następuje to w ciągu kilku dni od wykrycia, ale w rzadkich przypadkach może potrwać dłużej. Na przykład, unieważnienie certyfikatów wyciekłych kluczy atestacji jest zwykle opóźniane, jeśli urządzenia których dotyczy unieważnienie, można bezpiecznie ponownie udostępnić. Skala wpływu unieważnienia jest również ważnym czynnikiem w harmonogramach unieważnienia.

Sprawdzaj pary kluczy wspieranych sprzętowo za pomocą atestu kluczy

Zanim zaczniesz: upewnij się, że Twoje urządzenie obsługuje atestację klucza na poziomie sprzętowym

Pobieranie i weryfikowanie pary kluczy sprzętowych

Certyfikaty główne

Wycofywanie kluczy fabrycznych: zdalne udostępnianie kluczy (RKP)

Biblioteki weryfikacji atestacji

Lista stanu unieważnienia certyfikatów

Wygasłe klucze fabryczne: nadal zaufane

Zasady unieważniania certyfikatów

Co kwalifikuje się do unieważnienia?

Schemat danych rozszerzenia atestacji klucza

Schemat danych rozszerzenia informacji o udostępnianiu

Sprawdzaj pary kluczy wspieranych sprzętowo za pomocą atestu kluczy Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Zanim zaczniesz: upewnij się, że Twoje urządzenie obsługuje atestację klucza na poziomie sprzętowym

Pobieranie i weryfikowanie pary kluczy sprzętowych

Certyfikaty główne

Wycofywanie kluczy fabrycznych: zdalne udostępnianie kluczy (RKP)

Biblioteki weryfikacji atestacji

Lista stanu unieważnienia certyfikatów

Wygasłe klucze fabryczne: nadal zaufane

Zasady unieważniania certyfikatów

Co kwalifikuje się do unieważnienia?

Schemat danych rozszerzenia atestacji klucza

Schemat danych rozszerzenia informacji o udostępnianiu

Sprawdzaj pary kluczy wspieranych sprzętowo za pomocą atestu kluczy