Signed certificate timestamp
In Internet security, Signed Certificate Timestamp (SCT) Auditing is a Google-developed mechanism to verify the validity of digital certificates, specifically those used in Certificate Transparency (CT) standard. Its purpose is to validate SCTs, which are promises made by certificate log operators to certificate authorities to include their freshly made signature in their log.[1] These promises are augmented with MMD - Maximum Merge Delay - to assure that this addition occurs within a reasonable time frame.[2]
Background
[edit]In most browsers, supporting Certificate Transparency resolves to verifying the cryptographic validity of SCTs. Simply put, when the domain owners requests a certificate, the issuer (Certificate Authority, or CA) answers with two closely related digital certificates:
- The CA produces a certificate assuring the ownership of the domain by the entity that made the request (alongside a chain of trust leading to a root of trust.
- The CA notifies several CT loggers of this certificate, receives promises (SCT) to include them in their logs, and relays those promises to the domain owner.
SCT Auditing targets the missing link by verifying that the promises made by the loggers be fulfilled.
Approaches
[edit]Theoretically, the process of validating the fulfilment of the SCT promise should be played out relatively simply as it only contains querying loggers and verifying their responses, which should be a Merkle tree audit path[3] using simple cryptographic functions. In practice, it turns out to be difficult to deploy. As a result, Google Chrome offers two approaches to SCT auditing, Opt-in and Opt-out. Both paradigm work asynchronously, namely they do not affect browser performance. This is mainly because failure to verify SCT does not necessarily mean a security breach.
The Opt-in paradigm, as the name suggests, needs to be turned on explicitly and is only active in Enhanced Safe Browsing mode. In this mode, a random sample of hosts is chosen and sent to Google powered servers, who verify the validity of those hosts' certificates and their inclusion in the CT loggers. This approach poses a privacy threat, as sampled hosts are shared directly and plainly with Google.[4]
The Opt-out paradigm offers a more privacy-enhancing trade-off. This approach relies on the assumption that Google maintains a comprehensive list of promises (SCTs); this assumption is reasonable given that Google powers log monitors which should catch all log insertions, namely all promises once fulfilled. The way to achieve private SCT auditing in this approach is as follows. As before, it is only employed on a small fraction of hosts, namely a small fraction of SCTs. Given a previously unmet sampled SCT, the user performs a k-anonymous query - the user only sends a small number of prefix bytes of the SCT. Since there are many SCTs in Google's databases, this is not expected to identify the SCT (hence the underlying accessed hostname or URL) uniquely, but rather narrow down to a few options. Google responds with those options, and the user can verify that her complete SCT is included in the Google's database. If it is not, it is a security issue that can be investigated further.[5] It is noted that this approach may fail if the user does not wait the MMD (time to fulfil the promise), since during that time it is not guaranteed that the certificate be found in the CT loggers.
See also
[edit]References
[edit]- ^ "SoKL SCT Auditing in Certificate Transparency" (PDF).
{{cite web}}: CS1 maint: url-status (link) - ^ "How CT Works : Certificate Transparency". certificate.transparency.dev. Archived from the original on 2022-02-25. Retrieved 2022-02-25.
- ^ "RFC 6962 - Certificate Transparency".
{{cite web}}: CS1 maint: url-status (link) - ^ "Opt-in SCT Auditing (public)".
{{cite web}}: CS1 maint: url-status (link) - ^ "Opt-out SCT Auditing in Chrome".
{{cite web}}: CS1 maint: url-status (link)