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 magazynie kluczy obsługiwanym przez sprzęt urządzenia. W kolejnych sekcjach opisujemy, jak sprawdzić właściwości kluczy obsługiwanych przez sprzęt i jak interpretować dane rozszerzenia certyfikatów atestu.

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

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

Oprócz tego ważne jest, aby zweryfikować podpisy w łańcuchu certyfikatów i sprawdzić, czy żaden z kluczy w łańcuchu nie został odwołany. W tym celu sprawdź listę stanu odwołania certyfikatów. Jeśli wszystkie certyfikaty nie są prawidłowe, a klucz główny nie jest kluczem głównym Google, nie ufaj atestowi w pełni.

Pobieranie i weryfikowanie pary kluczy wspieranych sprzętowo

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ętu, certyfikat główny w tym łańcuchu jest podpisany kluczem głównym atestu, który jest bezpiecznie udostępniany w magazynie kluczy obsługiwanym przez sprzęt urządzenia.

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

Użyj obiektu KeyStore i jego metody getCertificateChain() , aby uzyskać odniesienie do łańcucha certyfikatów X.509 powiązanych z magazynem kluczy obsługiwanym przez sprzęt.
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 odwołania każdego certyfikatu, aby upewnić się, że żaden z nich nie został odwołany.
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ć dane rozszerzenia certyfikatu informacji o udostępnianiu z tego certyfikatu.

Więcej informacji znajdziesz w sekcji Rozszerzenie 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ć dane rozszerzenia certyfikatu atestacji klucza z tego certyfikatu.

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, próbując utworzyć fałszywe atesty dla niezaufanych kluczy.

Przykładowy kod atestacji klucza atestacji używa parsera ASN.1 z biblioteki Bouncy Castle do wyodrębniania danych rozszerzenia certyfikatu atestu. Możesz użyć tego przykładu jako odniesienia do utworzenia własnego parsera.

Więcej informacji znajdziesz w sekcji Schemat 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 wspierany sprzętowo.

Certyfikaty główne

Wiarygodność atestu 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 atestu podpisanych certyfikatem głównym atestu sprzętu Google. Pamiętaj, że atest nie był wymagany 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 atestu zawiera ten klucz publiczny i żaden z certyfikatów w łańcuchu nie został odwołany, 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 atestu.

Jeśli łańcuch atestu zawiera inny klucz publiczny, Google nie gwarantuje bezpieczeństwa sprzętu. Nie oznacza to, że Twój klucz został naruszony, tylko że atest 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 atestu, ale podpisany kluczem zakodowanym na stałe w kodzie źródłowym Androida. Ponieważ ten klucz podpisywania nie jest tajny, the atest mógł zostać utworzony przez atakującego, który udaje, że zapewnia bezpieczny sprzęt.
Drugą prawdopodobną przyczyną jest to, ż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 atestu. Zapoznaj się z dokumentacją producenta urządzenia. Pamiętaj, że Google nie wie o żadnym producencie urządzenia, który by to zrobił.

Rotacja certyfikatu głównego atestacji sprzętu

Google wprowadza nowy certyfikat główny na potrzeby atestacji klucza na Androidzie. Ta zmiana zwiększa bezpieczeństwo i niezawodność procesu atestacji w przypadku aplikacji zawierających poufne dane. Wygenerowano nowy klucz główny na potrzeby atestacji klucza na Androidzie (KeyMint). Nowy klucz główny to klucz ECDSA P-384.

Co musisz zrobić

Jeśli Twoja aplikacja korzysta z atestacji klucza na Androidzie, do 31 marca 2026 r. dodaj nowy certyfikat główny do magazynów zaufanych certyfikatów . Pobierz nowy i stary certyfikat z https://android.googleapis.com/attestation/root
Urządzenia, które korzystają z zdalnego udostępniania kluczy (RKP) zaczną otrzymywać certyfikaty oparte na tym nowym certyfikacie w lutym 2026 r. Do 10 kwietnia 2026 r. urządzenia z RKP będą używać wyłącznie nowego klucza głównego.
Zaktualizuj procesy atestacji, aby ufać zarówno nowym, jak i dotychczasowym certyfikatom głównym. Starsze urządzenia z kluczami udostępnionymi fabrycznie nie obsługują rotacji kluczy i nadal używają starego klucza głównego.
Sam schemat rozszerzenia certyfikatu pozostanie bez zmian. Zmieni się tylko klucz główny.
Nowy klucz główny będzie publicznie dostępny w postaci czytelnej dla człowieka i komputera.

Sprawdzone metody

Nie wysyłaj zapytań do punktu końcowego o zaufane klucze główne w czasie działania programu, ponieważ stwarza to zagrożenie dla bezpieczeństwa. Zmiany w kluczach głównych zaufania wprowadzaj w ramach formalnego procesu.

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

W przypadku urządzeń wprowadzonych na rynek z Androidem 16 system obsługuje tylko RKP. Ta zasada wycofuje klucze fabryczne. Usprawnia ona sposób udostępniania kluczy atestu 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 odwołać klucz, możesz ograniczyć odwołanie do jednego urządzenia.

Biblioteki weryfikacji atestu

Do weryfikacji łańcuchów certyfikatów atestacji klucza użyj biblioteki Kotlin do weryfikacji atestu. Ponadto ta biblioteka zawiera już nowe certyfikaty główne. 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 odwołania certyfikatów

Klucze atestu mogą zostać odwołane 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 sprawdzić stan każdego certyfikatu w łańcuchu atestu na oficjalnej liście stanu odwołania 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 odwołania wszystkich certyfikatów, które nie mają normalnego stanu ważności. Format pliku JSON jest zgodny z tą definicją schematu JSON (wersja robocza 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"
    }
  }
}

Zasady odwoływania certyfikatów

Atest stanowi podstawę przeciwdziałania nadużyciom i zaufania w ekosystemie Androida. Zapewnia on stronom zewnętrznym kryptograficznie weryfikowalny komunikat o stanie uruchomienia urządzenia.

Certyfikaty kluczy atestu na Androidzie zostaną odwołane, gdy klucze zostaną naruszone, ze względu na krytyczny charakter ważności atestu. W tej sekcji przedstawiamy zasady odwoływania certyfikatów. Zasady te będą prawdopodobnie ewoluować i z czasem będą obejmować dodatkowe przypadki.

Co kwalifikuje się do odwołania?

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

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

Po wykryciu certyfikaty atestu zostaną odwołane przez dodanie ich numerów seryjnych do listy odwołań. Zwykle nastąpi to w ciągu kilku dni od wykrycia, ale w rzadkich przypadkach może potrwać dłużej. Na przykład, odwołanie certyfikatów wyciekłych kluczy atestu jest zwykle opóźniane, jeśli urządzenia których dotyczy odwołanie, można bezpiecznie ponownie udostępnić. Skala wpływu odwołania jest również ważnym czynnikiem w przypadku harmonogramów odwołań.

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

Pobieranie i weryfikowanie pary kluczy wspieranych sprzętowo

Certyfikaty główne

Rotacja certyfikatu głównego atestacji sprzętu

Co musisz zrobić

Sprawdzone metody

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

Biblioteki weryfikacji atestu

Lista stanu odwołania certyfikatów

Zasady odwoływania certyfikatów

Co kwalifikuje się do odwołania?

Schemat danych rozszerzenia atestacji klucza

Schemat danych rozszerzenia informacji o udostępnianiu

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