Android Certificate Transparency-Richtlinie

Fragen zu dieser Richtlinie richten Sie bitte an das CT-Richtlinienforum: ct-policy@chromium.org

Wenn das TLS-Zertifikat (Transport Layer Security) einer Verbindung in einer App validiert wird, die Certificate Transparency aktiviert hat, wird es auf Einhaltung der Android-Richtlinie zur Zertifikatstransparenz (Certificate Transparency, CT) geprüft. Zertifikate, die von SCTs (Signed Certificate Timestamps) begleitet werden, die dieser Richtlinie entsprechen, gelten als CT-konform.

Die CT-Konformität wird durch ein Zertifikat und eine Reihe von begleitenden SCTs erreicht, die eine Reihe von technischen Anforderungen erfüllen, die von gängigen TLS-Bibliotheken (einschließlich der integrierten Conscrypt-Bibliothek) während der Zertifikatsvalidierung durchgesetzt werden und in dieser Richtlinie definiert sind.

Status von CT-Logs

Die CT-Konformität in Android wird durch die Auswertung von SCTs aus CT-Logs bestimmt. Außerdem wird geprüft, ob sich diese Logs zum Zeitpunkt der Prüfung im richtigen Status befinden. Ein CT-Logbuch kann folgende Status haben:

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

Um die Anforderungen für die CT-Konformität in Android besser zu verstehen, werden die Definition dieser Status, die Anforderungen an Logs in den einzelnen Status sowie die Auswirkungen dieser Status auf das Android-Verhalten in der CT Log Lifecycle Explainer-Dokumentation von Chrome ausführlich beschrieben.

CT-konforme Zertifikate

Ein TLS-Zertifikat ist CT-konform, wenn es von einer Reihe von SCTs begleitet wird, die mindestens eines der später definierten Kriterien erfüllen, je nachdem, wie die SCTs an Android übermittelt werden. In Android-Apps, in denen CT erzwungen wird, müssen alle öffentlich vertrauenswürdigen TLS-Zertifikate CT-konform sein, damit die Validierung erfolgreich ist. Zertifikate, die nicht in CT protokolliert wurden oder nicht genügend SCTs haben, gelten jedoch nicht als falsch ausgestellt.

Bei der Bewertung eines Zertifikats hinsichtlich der CT-Konformität berücksichtigt Android mehrere Faktoren, darunter die Anzahl der vorhandenen SCTs, wer den CT-Log betreibt, der die SCT ausgestellt hat, und in welchem Zustand sich der CT-Log, der die SCT ausgestellt hat, sowohl zum Zeitpunkt der Zertifikatsvalidierung als auch zum Zeitpunkt der Erstellung der SCT durch den CT-Log befand.

Je nachdem, wie die SCTs an Android übermittelt werden, kann die CT-Konformität erreicht werden, indem eines der folgenden Kriterien erfüllt wird:

Eingebettete SCTs:

  1. Mindestens ein eingebettetes SCT aus einem CT-Log, das zum Zeitpunkt der Prüfung Qualified, Usable oder ReadOnly war; und
  2. Es gibt eingebettete SCTs aus mindestens N unterschiedlichen CT-Logs, die zum Zeitpunkt der Prüfung Qualified, Usable, ReadOnly oder Retired waren. N ist in der folgenden Tabelle definiert.
  3. Unter den SCTs, die Anforderung 2 erfüllen, müssen mindestens zwei von verschiedenen CT-Log-Betreibern ausgestellt werden, die von Android anerkannt werden.
  4. Unter den SCTs, die Anforderung 2 erfüllen, muss mindestens eine SCT aus einem Log stammen, das von Android als RFC 6962-konform erkannt wird.
Gültigkeitsdauer des Zertifikats Anzahl der SCTs aus verschiedenen CT-Logs
<= 180 Tage 2
> 180 Tage 3

Über OCSP oder TLS bereitgestellte SCTs:

  1. Mindestens zwei SCTs aus einem CT-Log, das zum Zeitpunkt der Prüfung Qualified, Usable oder ReadOnly war; und
  2. Unter den SCTs, die Anforderung 1 erfüllen, müssen mindestens zwei von verschiedenen CT-Protokollbetreibern ausgestellt werden, die von Android anerkannt werden.
  3. Unter den SCTs, die Anforderung 1 erfüllen, muss mindestens eine SCT aus einem CT-Logbuch stammen, das von Android als RFC6962-konform erkannt wird.

Sowohl für eingebettete SCTs als auch für SCTs, die über OCSP oder TLS bereitgestellt werden, wird die Eindeutigkeit des Log-Betreibers als separate Einträge im Abschnitt „Betreiber“ der Log-Liste definiert.

In dem seltenen Fall, dass ein CT-Log während seines Lebenszyklus den Betreiber wechselt, enthält es optional eine Liste von previous_operators, zusammen mit dem letzten Zeitstempel, zu dem dieses Log vom vorherigen Betreiber betrieben wurde. Damit Änderungen am Log-Betreiber nicht zu Problemen mit vorhandenen Zertifikaten führen, wird der Log-Betreiber jedes SCT anhand des Zeitstempels des SCT und der previous_operators-Zeitstempel (falls vorhanden) als der Betreiber zum Zeitpunkt der SCT-Ausstellung bestimmt.

Wichtige Hinweise

Solange eines der oben genannten CT-Compliance-Kriterien durch eine Kombination von SCTs erfüllt wird, die im Handshake präsentiert werden, wirken sich zusätzliche SCTs, unabhängig vom Status der SCT, nicht positiv oder negativ auf den CT-Compliance-Status eines Zertifikats aus.

Damit ein SCT zur CT-Konformität eines Zertifikats beitragen kann, muss es vor dem Retired-Zeitstempel des Logs ausgestellt worden sein, sofern ein solcher vorhanden ist. Unter Android wird der früheste SCT unter allen präsentierten SCTs verwendet, um die CT-Konformität anhand der Zeitstempel des CT-Logs Retired zu bewerten. So werden Grenzfälle berücksichtigt, in denen ein CT-Log während des Prozesses zum Senden von Zertifikats-Logging-Anfragen in den Status „Retired“ (Eingestellt) wechselt.

„Eingebettetes SCT“ bedeutet ein SCT, das über die SignedCertificateTimestampList-X.509v3-Erweiterung im Zertifikat selbst bereitgestellt wird. Viele TLS-Server unterstützen OCSP-Stapling oder die TLS-Erweiterung nicht. Zertifizierungsstellen sollten daher SCTs in ausgestellte Zertifikate einbetten, um eine erfolgreiche Validierung oder EV-Behandlung in Android zu gewährleisten.

So werden CT-Logs zu Android hinzugefügt

Die Kriterien dafür, wie CT-Logs Qualified werden können, sowie die Umstände, die dazu führen können, dass sie Retired werden, finden Sie in der Chrome CT Log Policy.

CT-Durchsetzungszeitlimit

Jeden Tag veröffentlicht Google eine neue CT-Log-Liste, die einen neuen log_list_timestamp enthält. Android-Geräte versuchen einmal täglich, die aktuelle Version dieser Liste zu Prüfzwecken herunterzuladen. Wenn zu einem bestimmten Zeitpunkt keine Logliste auf dem Gerät verfügbar ist oder der Zeitstempel der Logliste älter als 70 Tage ist, wird die CT-Durchsetzung deaktiviert. Dieses Zeitlimit bietet dem CT-Ökosystem die wichtige Sicherheit, dass neue CT-Logs innerhalb einer bestimmten Zeit nach dem Status Qualified sicher in den Status „Usable“ (Verwendbar) übergehen können.

Android-Protokollliste

Die Android-Logliste wird in log_list.json veröffentlicht und täglich aktualisiert. Diese Logliste wird ohne stabile API, SLA oder Verfügbarkeitsgarantien angeboten.

Android stellt seine CT-Logliste für Zertifikatsender (z. B. Zertifizierungsstellen) sowie CT-Monitore und ‑Prüfer zur Verfügung, die mit den CT- und WebPKI-Ökosystemen kompatibel bleiben oder deren Inhalte untersuchen möchten.

Das unbefugte Verlassen auf die Android-CT-Logliste gefährdet nicht nur Ihre Nutzer, sondern Android-Nutzer und das CT-System als Ganzes. Wenn Sie die Durchsetzung von Zertifikaten in Ihre App einbauen möchten, verwenden Sie einen von der Android-Plattform unterstützten Mechanismus.

Die Verwendung der Android-CT-Logliste, die nicht dieser Richtlinie entspricht, erfolgt auf eigenes Risiko und kann dazu führen, dass Ihre Anwendung oder Bibliothek nicht mehr funktioniert. Android muss in der Lage sein, Änderungen an der CT-Protokollliste vorzunehmen, um auf Vorfälle im CT-Ökosystem zu reagieren und die Sicherheit von Android-Nutzern zu gewährleisten. Android kann Maßnahmen ergreifen, um sicherzustellen, dass Drittanbieterabhängigkeiten von der CT-Logliste die Fähigkeit von Android, auf solche Vorfälle zu reagieren, nicht gefährden. Dazu gehören auch nicht angekündigte Änderungen an der Logliste, um die unbefugte Nutzung zu unterbinden.