Ta strona została przetłumaczona przez Cloud Translation API.

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

Potwierdzenie klucza zwiększa pewność, że klucze używane w aplikacji są przechowywane w sprzętowym magazynie kluczy urządzenia. W poniższych sekcjach opisano, jak weryfikować właściwości kluczy obsługiwanych przez sprzęt i jak interpretować dane rozszerzeń certyfikatów atestatycznych.

Uwaga: zanim zweryfikujesz właściwości kluczy sprzętowych urządzenia w środowisku produkcyjnym, upewnij się, że urządzenie obsługuje uwierzytelnianie klucza na poziomie sprzętu. W tym celu sprawdź, czy łańcuch certyfikatu atesta zawiera certyfikat główny, który jest podpisany kluczem głównym atesta Google, oraz czy element attestationSecurityLevel w strukturze danych opis klucza ma ustawiony poziom zabezpieczeń TrustedEnvironment lub StrongBox.

Ponadto ważne jest, aby zweryfikować podpisy w łańcuchu certyfikatów i sprawdzić, czy żaden z kluczy w łańcuchu nie został cofnięty. Aby to zrobić, sprawdź listę stanów cofnięcia certyfikatu. Jeśli nie wszystkie są prawidłowe i głównym kluczem jest klucz główny Google, nie należy w pełni ufać uwierzytelnieniu.

Pobieranie i weryfikowanie pary kluczy obsługiwanych sprzętowo

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

Jeśli urządzenie obsługuje uwierzytelnianie klucza na poziomie sprzętu, certyfikat główny w tym łańcuchu jest podpisany za pomocą klucza głównego uwierzytelniania, który jest bezpiecznie udostępniany w sprzętowym magazynie kluczy urządzenia.

Uwaga: na urządzeniach z weryfikacją klucza na poziomie sprzętu, Androidem 7.0 (poziom interfejsu API 24) lub nowszym oraz Usługami Google Play certyfikat główny jest podpisany kluczem głównym weryfikacji Google. Sprawdź, czy ten certyfikat główny znajduje się na liście certyfikatów głównych.

Aby wdrożyć weryfikację klucza, wykonaj te czynności:

Użyj metody KeyStore obiektu getCertificateChain(), aby uzyskać odwołanie do łańcucha certyfikatów X.509 powiązanych z magazynem kluczy obsługiwanym sprzętowo.
Prześlij certyfikaty na oddzielny serwer, któremu ufasz, w celu ich zweryfikowania.

Uwaga: nie przeprowadzaj tego procesu weryfikacji na tym samym urządzeniu, na którym znajduje się KeyStore. Jeśli system Android na tym urządzeniu został przejęty, proces weryfikacji może zaufać niewiarygodnemu elementowi.
Uzyskaj odwołanie do biblioteki parsowania i weryfikacji łańcucha certyfikatów X.509, która jest najbardziej odpowiednia dla Twojego zestawu narzędzi. Sprawdź, czy certyfikat publiczny wierzchołka jest wiarygodny 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 sprawdź rozszerzenie certyfikatu informacji o zarządzaniu, które występuje tylko w nowszych łańcuchach certyfikatów.

Uzyskaj odwołanie do biblioteki parsowania CBOR, która jest najbardziej odpowiednia dla Twojego zestawu narzędzi. Znajdź certyfikat najbliżej głównego, który zawiera rozszerzenie certyfikatu informacji o inicjowaniu. Użyj parsera, aby wyodrębnić z tego certyfikatu dane rozszerzenia certyfikatu informacji.

Więcej informacji znajdziesz w sekcji dotyczącej rozszerzenia informacji o inicjowaniu.
Uzyskaj odwołanie do biblioteki parsowania ASN.1, która jest najbardziej odpowiednia dla Twojego zestawu narzędzi. Znajdź najbliższy certyfikat główny, który zawiera rozszerzenie certyfikatu atestackiego klucza. Jeśli rozszerzenie certyfikatu z informacjami o obsługi administracyjnej było obecne, rozszerzenie certyfikatu poświadczenia klucza musi znajdować się w następnym certyfikacie. Użyj parsowania, aby wyodrębnić z tego certyfikatu dane rozszerzenia certyfikatu atesta.

Ostrzeżenie: nie zakładaj, że rozszerzenie certyfikatu poświadczenia klucza znajduje się w certyfikacie końcowym łańcucha. Tylko pierwsze wystąpienie rozszerzenia w łańcuchu może być wiarygodne. Wszystkie kolejne instancje rozszerzenia nie zostały wydane przez bezpieczny sprzęt i mogą być wydane przez atakującego, który rozszerzył łańcuch, próbując utworzyć fałszywe oświadczenia dla niezaufanych kluczy.

Plik z atestem klucza używa parsowania ASN.1 z Bouncy Castle do wyodrębniania danych rozszerzenia certyfikatu atesta. Możesz użyć tego przykładu jako punktu odniesienia do utworzenia własnego parsowania.

Więcej informacji znajdziesz w sekcji dotyczącej schematu danych rozszerzenia weryfikacji klucza.
Sprawdź spójność danych rozszerzenia uzyskanych w poprzednich krokach i porównaj je z zestawem wartości, które powinien zawierać klucz oparty na sprzęcie.

Certyfikaty główne

Zaufanie do zaświadczeń zależy od certyfikatu głównego łańcucha. Urządzenia z Androidem, które przeszły testy wymagane do obsługi pakietu aplikacji Google, w tym Google Play, i które zostały uruchomione z Androidem 7.0 (poziom interfejsu API 24) lub nowszym, powinny używać kluczy uwierzytelniania podpisanych certyfikatem ROOT Google Hardware Attestation. Pamiętaj, że do wersji Androida 8.0 (poziom API 26) nie było wymagane uwierzytelnianie. Klucz publiczny głównego węzła ma postać:

Wydane wcześniej certyfikaty główne

Jeśli otrzymany certyfikat główny w łańcuchu potwierdzenia zawiera ten klucz publiczny i żaden z certyfikatów w łańcuchu nie został cofnięty, pamiętaj, że:

klucz jest przechowywany na sprzęcie, który według Google jest bezpieczny;
Ma właściwości opisane w certyfikacie.

Jeśli łańcuch uwierzytelniania zawiera inny klucz publiczny głównego wierzchołka, Google nie składa żadnych oświadczeń dotyczących bezpieczeństwa sprzętu. Nie oznacza to, że klucz został skompromitowany, tylko że poświadczenia nie potwierdzają, że klucz jest na bezpiecznym sprzęcie. Dostosuj odpowiednio założenia dotyczące zabezpieczeń.

Jeśli certyfikat główny nie zawiera klucza publicznego na tej stronie, może to być spowodowane 2 prawdopodobnymi przyczynami:

Najprawdopodobniej urządzenie zostało uruchomione z wersją Androida niższą niż 7.0 i nie obsługuje weryfikacji za pomocą sprzętu. W tym przypadku Android ma implementację oprogramowania do przeprowadzania atesta, która generuje ten sam rodzaj certyfikatu, ale podpisany kluczem zakodowanym na stałe w źródle Androida. Ponieważ ten klucz podpisywania nie jest tajny, poświadczenie może zostać utworzone przez osobę atakującą, która udaje, że udostępnia bezpieczny sprzęt.
Innym prawdopodobnym powodem jest to, że urządzenie nie jest urządzeniem Google Play. W takim przypadku producent urządzenia może utworzyć własny rdzeń i stwierdzić, cokolwiek zechce, na temat tego, co oznacza atestat. Zapoznaj się z dokumentacją producenta urządzenia. Pamiętaj, że Google nie wie o żadnym takim przypadku.

Lista stanów odwołania certyfikatów

Klucze uwierzytelniające mogą zostać cofnięte z różnych powodów, w tym z powodu niewłaściwego ich użycia lub podejrzenia o wydobycie przez atakującego. Dlatego tak ważne jest, aby stan każdego certyfikatu w łańcuchu dokumentów potwierdzających został sprawdzony na liście oficjalnych certyfikatów odwołanych (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 sprawdzać dostępność aktualizacji, aby nie wymagać wysyłania prośby do sieci w przypadku każdego weryfikowanego certyfikatu. Ten adres URL zwraca plik JSON zawierający stan odwołania wszystkich certyfikatów, które nie mają zwykłego stanu prawidłowego. Format pliku JSON musi być zgodny z definicją schematu JSON (wersja 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ładowy plik 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

Potwierdzenie to podstawa zapobiegania nadużyciom i budowania zaufania w ekosystemie Androida. Zapewnia ona podmiotom zewnętrznym weryfikowalne kryptograficznie oświadczenie dotyczące stanu urządzenia po uruchomieniu.

Ze względu na kluczowe znaczenie ważności potwierdzenia certyfikaty kluczy potwierdzających Androida zostaną unieważnione, gdy klucze zostaną naruszone. W tej sekcji opisaliśmy zasady dotyczące odwoływania certyfikatów. Te zasady mogą się z czasem zmieniać i obejmować dodatkowe przypadki.

Jakie warunki musi spełniać odwołanie?

Wycieki kluczy uwierzytelniających dotyczą tylko starszego mechanizmu obsługiwanego w Androidzie i nie mają zastosowania do kluczy uwierzytelniających certyfikowanych przez nowszy mechanizm zdalnego obsługi kluczy.

W przypadku kluczy uwierzytelniających, które wyciekły, zawsze można unieważnić ich certyfikaty. Wycieki mogą być wykrywane na wiele sposobów, m.in.:

Analiza danych dotyczących weryfikacji w praktyce.
odnalezienie kluczy uwierzytelniających w mediach społecznościowych lub na innych stronach publicznych;
raporty bezpośrednio od badaczy zabezpieczeń;

Po wykryciu certyfikaty zostaną unieważnione przez dodanie ich numerów seryjnych do listy odwołanych certyfikatów. Zwykle zajmuje to kilka dni, ale w niektórych przypadkach może potrwać dłużej. Na przykład unieważnienie certyfikatów w przypadku wycieku kluczy uwierzytelniających jest zwykle opóźnione, jeśli urządzenia, których dotyczy unieważnienie, można bezpiecznie ponownie skonfigurować. Ważnym czynnikiem wpływającym na czas trwania procesu cofnięcia jest też skala wpływu cofnięcia.