Zasady Certificate Transparency w Androidzie

Wszelkie pytania dotyczące tej Polityki należy kierować na forum Polityki dotyczącej CT: ct-policy@chromium.org

Gdy certyfikat Transport Layer Security (TLS) połączenia jest weryfikowany w aplikacji, która zaakceptowała przejrzystość certyfikatów, jest on oceniany pod kątem zgodności z zasadami przejrzystości certyfikatów Androida (CT). Certyfikaty, które zawierają podpisany sygnaturą czasową certyfikat (SCT) zgodny z tymi zasadami, są uznawane za zgodne z CT.

Zgodność z protokołem CT jest osiągana przez certyfikat i zbiór towarzyszących mu SCT, które spełniają zestaw wymagań technicznych egzekwowanych przez popularne biblioteki TLS (w tym wbudowany Conscrypt w Androidzie) podczas weryfikacji certyfikatu, które są określone w tych Zasadach.

Stany logów CT

Zgodność z certyfikatem CT na Androidzie jest określana przez sprawdzenie SCT z logów CT i upewnienie się, że te logi są w prawidłowym stanie w momencie sprawdzania. Zestaw możliwych stanów dziennika CT:

  • Pending
  • Qualified
  • Usable
  • ReadOnly
  • Retired
  • Rejected

Aby pomóc Ci zrozumieć wymagania dotyczące zgodności z CT w Androidzie, definicję tych stanów, wymagania dotyczące dzienników w każdym stanie, a także sposób, w jaki stany te wpływają na działanie Androida, przeczytaj szczegółowe informacje w artykule CT Log Lifecycle Explainer w dokumentacji Chrome.

Certyfikaty zgodne z CT

Certyfikat TLS jest zgodny z CT, jeśli jest dołączony do zestawu SCT, który spełnia co najmniej 1 z wymienionych poniżej kryteriów (w zależności od sposobu dostarczania SCT do Androida). W aplikacji na Androida, która wymaga stosowania CT, wszystkie publicznie zaufane certyfikaty TLS muszą być zgodne z protokołem CT, aby można je było zweryfikować. Jednak certyfikaty, które nie są rejestrowane w CT lub mają niewystarczającą liczbę SCT, nie są uważane za nieprawidłowo wydane.

Podczas sprawdzania certyfikatu pod kątem zgodności z protokołem CT Android bierze pod uwagę kilka czynników, w tym liczbę obecnych podpisów czasowych, operatora dziennika CT, który wydał podpis czasowy, oraz stan dziennika CT, który wydał podpis czasowy, zarówno w momencie sprawdzania certyfikatu, jak i w momencie utworzenia podpisu czasowego przez dziennik CT.

W zależności od tego, jak SCT są prezentowane w Androidzie, zgodność z zasadami CT można osiągnąć, spełniając jedno z tych kryteriów:

Umieszczone w filmie scenariusze:

  1. co najmniej 1 osadzony certyfikat SCT z dziennika CT, który w momencie sprawdzania miał stan Qualified, Usable lub ReadOnly;
  2. w ramach SCT są zakodowane certyfikaty CT z co najmniej N różnych dzienników CT, które w momencie sprawdzania miały stan Qualified, Usable, ReadOnly lub Retired, gdzie N zostało zdefiniowane w tabeli poniżej;
  3. Spośród SCT spełniających wymóg 2 co najmniej 2 SCT muszą być wydane przez różnych operatorów logów CT rozpoznawanych przez Androida;
  4. Spośród SCT spełniających wymagania 2 co najmniej jeden musi być wydany z dziennika uznanego przez Androida za zgodny z wytycznymi RFC 6962.
Czas ważności certyfikatu Liczba SCT z różnych plików dziennika CT
<= 180 dni 2
> 180 dni 3

SCT dostarczane za pomocą OCSP lub TLS:

  1. co najmniej 2 certyfikaty SCT z dziennika CT, który w momencie sprawdzania miał stan Qualified, Usable lub ReadOnly;
  2. Spośród SCT spełniających wymagania 1 co najmniej 2 SCT muszą być wydane przez różnych operatorów logów CT rozpoznawanych przez Androida;
  3. Spośród SCT spełniających wymóg 1 co najmniej jeden musi być wydany z logów CT uznanych przez Androida za zgodne z RFC 6962.

Zarówno w przypadku osadzonych SCT, jak i tych dostarczanych za pomocą OCSP lub TLS, unikalność operatora logowania jest zdefiniowana jako posiadanie oddzielnych wpisów w sekcji operatorów w pliku log_list.json1.

W rzadkich przypadkach, gdy log CT zmienia operatorów w trakcie swojego działania, logi CT opcjonalnie zawierają listę previous_operators, której towarzyszy ostatni znacznik czasu, w którym ten log był obsługiwany przez poprzedniego operatora. Aby zmiany operatora logów nie powodowały uszkodzenia istniejących certyfikatów, operator logów każdego SCT jest określany jako operator w momencie wydania SCT, poprzez porównanie sygnatury czasowej SCT z sygnaturą czasową previous_operators, jeśli jest dostępna.

Ważne uwagi

Dopóki jedno z powyżej wymienionych kryteriów zgodności z certyfikatem CT jest spełnione przez dowolną kombinację SCT przedstawionych w porozumieniu, dodatkowe SCT, niezależnie od ich stanu, nie będą miały wpływu na stan zgodności z certyfikatem CT.

Aby przyczynić się do zgodności certyfikatu z certyfikatem CT, należy wydać SCT przed sygnaturą czasową Retired w dzienniku (jeśli taka istnieje). Android używa najstarszego SCT spośród wszystkich przedstawionych, aby ocenić zgodność z CT na podstawie sygnatur czasowych z CT Log Retired. Jest to uwzględnione w przypadkach, gdy log CT staje się nieaktualny w trakcie przesyłania żądań rejestrowania certyfikatów.

„Zewnętrzna sygnatura czasowa podpisanego certyfikatu” to sygnatura czasowa podpisanego certyfikatu dostarczona za pomocą rozszerzenia SignedCertificateTimestampListX.509v3 w samym certyfikacie. Wiele serwerów TLS nie obsługuje przypinania OCSP ani rozszerzenia TLS, dlatego urzędy certyfikacji powinny być przygotowane na umieszczanie SCT w wydanych certyfikatach, aby zapewnić prawidłową weryfikację lub traktowanie jako EV na urządzeniach z Androidem.

Dodawanie dzienników CT do Androida

Kryteria, według których dzienniki CT mogą stać się Qualified, a także okoliczności, które mogą spowodować, że staną się one Retired, znajdziesz w zasadach dotyczących dzienników CT w Chrome.

Czas oczekiwania na egzekwowanie zasad CT

Google publikuje codziennie nową listę CT Log, która zawiera aktualne log_list_timestamp. Raz dziennie urządzenia z Androidem będą próbować pobrać najnowszą wersję tej listy na potrzeby weryfikacji. Jeśli na urządzeniu nie ma listy logów lub jej sygnatura czasowa jest starsza niż 70 dni, egzekwowanie CT zostanie wyłączone. Ten limit czasu zapewnia ekosystemowi CT gwarancję, że nowe dzienniki CT mogą bezpiecznie przejść do stanu „Można użyć” w określonym czasie po tym, jak staną się dostępne (Qualified).


  1. Pamiętaj, że opublikowana lista logów nie zapewnia stabilnego interfejsu API ani gwarancji dostępności. Nie należy na niej polegać.