Zasady Certificate Transparency w Androidzie

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

Gdy certyfikat TLS połączenia jest weryfikowany w aplikacji, która korzysta z przejrzystości certyfikatów, jest on oceniany pod kątem zgodności z zasadami przejrzystości certyfikatów na Androidzie. Certyfikaty, którym towarzyszą sygnatury czasowe certyfikatu (SCT) spełniające te zasady, są uznawane za zgodne z CT.

Zgodność z protokołem CT jest osiągana, gdy certyfikat i zestaw towarzyszących mu SCT spełniają zestaw wymagań technicznych egzekwowanych przez popularne biblioteki TLS (w tym wbudowaną bibliotekę Conscrypt) podczas weryfikacji certyfikatu, które są zdefiniowane w niniejszych zasadach.

Stany logów CT

Zgodność z CT na Androidzie jest określana na podstawie oceny SCT z logów CT i sprawdzania, czy w momencie sprawdzania logi te są w odpowiednim stanie. Zbiór możliwych stanów dziennika CT:

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

Aby pomóc w zrozumieniu wymagań dotyczących zgodności z CT na Androidzie, definicje tych stanów, wymagania dotyczące dzienników w każdym stanie oraz wpływ tych stanów na działanie Androida zostały szczegółowo opisane w wyjaśnieniu cyklu życia dziennika CT w dokumentacji Chrome.

Certyfikaty zgodne z CT

Certyfikat TLS jest zgodny z CT, jeśli towarzyszy mu zestaw SCT, który spełnia co najmniej jedno z kryteriów zdefiniowanych poniżej, w zależności od sposobu dostarczania SCT do Androida. W aplikacjach na Androida, w których obowiązuje CT, wszystkie publicznie zaufane certyfikaty TLS muszą być zgodne z CT, aby można było je prawidłowo zweryfikować. Certyfikaty, które nie są rejestrowane w CT lub mają niewystarczającą liczbę SCT, nie są jednak uznawane za nieprawidłowo wydane.

Podczas oceny certyfikatu pod kątem zgodności z CT Android bierze pod uwagę kilka czynników, w tym liczbę sygnatur czasowych podpisanego certyfikatu (SCT), operatora dziennika CT, który wydał SCT, oraz stan dziennika CT, który wydał SCT, zarówno w momencie weryfikacji certyfikatu, jak i w momencie utworzenia SCT przez dziennik CT.

W zależności od sposobu prezentowania SCT na urządzeniach z Androidem zgodność z CT można osiągnąć, spełniając jedno z tych kryteriów:

Osadzone SCT:

  1. co najmniej 1 osadzony SCT z dziennika CT, który w momencie sprawdzania miał stan Qualified, Usable lub ReadOnly;
  2. Istnieją osadzone SCT z co najmniej N różnych dzienników CT, które w momencie sprawdzania miały stan Qualified, Usable, ReadOnly lub Retired, gdzie N jest zdefiniowane w tej tabeli;
  3. Wśród SCT spełniających wymaganie 2 co najmniej 2 SCT muszą być wydane przez różnych operatorów dzienników CT uznawanych przez Androida.
  4. Wśród SCT spełniających wymaganie 2 co najmniej jeden SCT musi być wydany przez dziennik uznawany przez Androida za zgodny z RFC 6962.
Okres ważności certyfikatu Liczba SCT z różnych dzienników CT
<= 180 dni 2
> 180 dni 3

SCT dostarczane za pomocą protokołu OCSP lub TLS:

  1. co najmniej 2 SCT z dziennika CT, który w momencie sprawdzania miał stan Qualified, Usable lub ReadOnly;
  2. Wśród SCT spełniających wymaganie 1 co najmniej 2 SCT muszą być wydane przez różnych operatorów dzienników CT uznawanych przez Androida;
  3. Wśród certyfikatów SCT spełniających wymaganie 1 co najmniej 1 musi być wydany na podstawie dziennika CT uznawanego przez Androida za zgodny z RFC6962.

W przypadku osadzonych sygnatur SCT i sygnatur dostarczanych za pomocą protokołów OCSP lub TLS niepowtarzalność operatora dziennika jest definiowana jako oddzielne wpisy w sekcji operatorów na liście dzienników.

W rzadkich przypadkach, gdy dziennik CT zmienia operatora w trakcie swojego działania, może zawierać listę previous_operators wraz z ostateczną sygnaturą czasową, która wskazuje, kiedy dziennik był obsługiwany przez poprzedniego operatora. Aby zapobiec przerwaniu działania istniejących certyfikatów w wyniku zmian operatora dziennika, operator każdego SCT jest określany jako operator w momencie wydania SCT przez porównanie sygnatury czasowej SCT z sygnaturami czasowymi previous_operators, jeśli są obecne.

Ważne informacje

Jeśli któreś z powyższych kryteriów zgodności z CT jest spełnione przez pewną kombinację SCT przedstawionych w procesie uzgadniania połączenia, dodatkowe SCT, niezależnie od ich stanu, nie będą miały pozytywnego ani negatywnego wpływu na stan zgodności certyfikatu z CT.

Aby przyczynić się do zgodności certyfikatu z CT, SCT musi zostać wydany przed sygnaturą czasową Retired dziennika, jeśli taka istnieje. Android używa najwcześniejszego SCT spośród wszystkich SCT, aby ocenić zgodność z CT na podstawie sygnatur czasowych w logu CT Retired. Uwzględnia to przypadki graniczne, w których dziennik CT zostaje wycofany podczas procesu przesyłania żądań rejestracji certyfikatów.

„Osadzona sygnatura czasowa podpisanego certyfikatu” oznacza sygnaturę czasową podpisanego certyfikatu dostarczoną za pomocą rozszerzenia SignedCertificateTimestampListX.509v3 w samym certyfikacie. Wiele serwerów TLS nie obsługuje OCSP Stapling ani rozszerzenia TLS, więc urzędy certyfikacji powinny być przygotowane na osadzanie SCT w wydawanych certyfikatach, aby zapewnić prawidłową weryfikację lub traktowanie certyfikatów EV w Androidzie.

Jak dzienniki CT są dodawane do Androida

Kryteria, które decydują o tym, kiedy dzienniki CT mogą uzyskać stan Qualified, oraz okoliczności, w których mogą uzyskać stan Retired, znajdziesz w zasadach Chrome CT Log Policy.

CT Enforcement Timeout

Każdego dnia Google publikuje nową listę dzienników CT, która zawiera świeże log_list_timestamp. Urządzenia z Androidem będą raz dziennie próbować pobrać najnowszą wersję tej listy w celu weryfikacji. Jeśli w danym momencie na urządzeniu nie jest dostępna lista logów lub sygnatura czasowa listy logów jest starsza niż 70 dni, egzekwowanie CT zostanie wyłączone. Ten limit czasu zapewnia ekosystemowi CT, że nowe dzienniki CT mogą bezpiecznie przejść do stanu „Usable” w określonym czasie po osiągnięciu stanu Qualified.

Lista logów Androida

Lista dzienników Androida jest publikowana w pliku log_list.json, który jest aktualizowany codziennie. Ta lista logów jest udostępniana bez stabilnego interfejsu API, umowy SLA ani gwarancji dostępności.

Android udostępnia listę dzienników CT podmiotom przesyłającym certyfikaty (np. urzędom certyfikacji) oraz monitorom i audytorom CT, którzy chcą zachować zgodność z ekosystemami CT i WebPKI lub badać ich zawartość.

Nieuprawnione korzystanie z listy logów CT na Androidzie zagraża nie tylko Twoim użytkownikom, ale też użytkownikom Androida i całemu ekosystemowi CT. Jeśli chcesz dodać do aplikacji egzekwowanie CT, użyj mechanizmu obsługiwanego przez platformę Android.

Korzystanie z listy dzienników przejrzystości certyfikatów Androida niezgodnie z tymi zasadami odbywa się na Twoje własne ryzyko i może spowodować awarię aplikacji lub biblioteki. Android musi mieć możliwość wprowadzania zmian na liście dzienników CT w odpowiedzi na incydenty w ekosystemie CT, aby zachować bezpieczeństwo użytkowników Androida. Android może podjąć działania, aby zapewnić, że zależności od listy logów CT w przypadku innych firm nie będą zagrażać możliwości reagowania Androida na takie incydenty, w tym nieogłoszone zmiany na liście logów, które mają na celu przerwanie nieautoryzowanego użycia.