Certificate transparency – quick fraud detection

In this blog, we discuss certificate transparency and how it can help quickly detect fraudulent certificates.

SSL trust issues

India's National Informatics Centre (NIC) has joined the infamous Dutch CA DigiNotar in issuing fake and unauthorised digital certificates. Yet again, this activity damages the faith we place in Certification Authorities (CAs) to provide high-trust identity assurance.
The NIC CA is chained to India’s Controller of Certifying Authorities (CCA) Root CA which is included in all copies of Microsoft’s Trusted Root Certification Authority Store.

Thus, any SSL certificate issued (i.e. signed) by NIC is automatically trusted by Windows systems and, of course, Internet Explorer. It is also trusted by Google Chrome and other browsers that use Windows-trusted certificate stores.

In July 2014, Google identified that the NIC CA had issued fake Google certificates and immediately informed CCA who revoked NIC issued certificates.

Google blocked all the fraudulently issued certificates to stop any further damage. Such events occur because of poor policy and procedures and poor IT physical and logical security.

To prevent such breaches occurring again, stronger trust is needed that features a fast and open detection mechanism.

A solution for enhanced trust

Google’s answer to these issues has been Certificate Transparency. This approach requires CAs to publicly publish information about their issued certificates so that anyone can check whether a certificate has been properly issued.

Certificate Transparency (CT) does not stop fraudulent certificates being created, but it enables them to be quickly and easily detected. The CT solution uses three new entities: 

1. Log Servers - These accept a yet to be issued certificate from a CA and return an SCT (Signed Certificate Time Stamp); a proof that the certificate has been received by the Log Server.
   
   The CA then embeds the SCT inside the issued certificate. Alternatively a CA’s OCSP Server can acquire SCTs for its certificate and place these inside OCSP responses. In either case the SCT data is processed by the end entity software, such as a browser.
   
   
2. Auditor - This is a lightweight software component used to check that a certificate does appear within a log, they also verify that the log server is behaving correctly and that they are cryptographically consistent.
   
   
3. Monitors - These are servers that constantly review log servers and watch for suspicious certificates, they may be run by large organisations to ensure that fraudulent certificates have not been issued or watch for certificates that have unusual certificate extensions.
   
   

Why Certificate Transparency is important

Certificate Transparency is an open framework that can quickly detect digital certificate trust threats. It brings automatic checks and openness to the SSL certificate system.

1. Early detection of fraudulent certificates and CAs - CT provides much faster detection of fraudulent certificates in hours rather than days.
   
   
2. Faster resolution - CT enables quicker detection and thus enables faster problem resolution, by using standard procedures like revoking the fraudulent digital certificates.
   
   
3. Better oversight of the TLS/SSL system - CT is an open framework that allows any third party to observe and verify the integrity of Server SSL certificates, e.g. domain owners, the CAs.
   
   

How is SCT data used by end systems?

1. Trusted CAs put the SCT data within SSL Server Certificates as an X.509 extension so that any software (such as a browser) can see and verify the SCT data. From February 2015 Google’s Chrome browser will no longer show the green Enhanced Validation (EV) indicator for certificates that do not have embedded SCT data.
   
   More details are provided within the EV CT Plan.
   
   
2. For those CAs that cannot make this change in time, the alternative is to use OCSP Stapling. There are two methods:
   
   
   • The web server communicates with the CA's OCSP repsponder, gets an OCSP with SCT embedded a an extension. The webserver then extracts the SCT to use it within the TLS/SSL handshake
     
     
   • The web server communicates with the log server to get an SCT, which is later sent by using the TLS handshake
     
     

ADSS Server and Certificate Transparency

The ADSS Server Q4 2014 release supports Certificate Transparency and offers these features:

1. ADSS CA Server will have an option in the SSL Certificate Template to include SCT data.
   
   
2. ADSS Server Certification Service will request an SCT for an SSL Server Certificate as it is being created and embed this as a certificate extension as described above.
   
   
3. Log Server URL(s) will be configurable for each CA.
   
   
4. Following RFC 6962, ADSS Server will be able to embed more than one SCT. The recommendation is to use SCTs from 3 different Log Servers so that SSL clients can select any of the SCTs. Each CA will have a policy setting that defines the number of SCTs to be retrieved. If ADSS CA Server fails to get this number of SCTs then the certificate will not be issued. 
   
   
5. SCTs are trust checked before being embedded within certificates and then they are stored in the database for future quick access.
   
   
6. The ADSS Server transaction logs viewer will allow a certificate’s SCT data to be viewed.

Ascertia strongly supports high trust initiatives which make the internet a safer place for governments, business and consumers. Certificate Transparency is a good open approach to strengthen the way in which Server SSL certificates can be trust checked and make it easier to detect fraud.

Contact us for more information about how Ascertia can help increase Certificate Transparency and reduce fraud.