Sunday, April 17, 2016

Certificate Transparency

When sensitive data is transferred between two hosts, an encrypted communication like TLS is used for that purpose. And, digital certificates have a major role to play in TLS communication.

A TLS server usually issues its digital certificate from a trusted Certificate Authority or CA. When a TLS client wants to establish a TLS connection with the server, the server sends that digital certificate to the client. The client verifies the certificate from the trusted CA and then proceeds with establishing the connection.


But, there are a number of recent incidences where a digital certificate is mistakenly issued by a CA or a CA has been compromised. It is extremely difficult to detect such fraudulent cases in current scenario. Our browsers cannot detect if a malicious website is using a mistakenly issued certificate or a certificate issued by a compromised or rogue CA. As a result, user security gets compromised.


Certificate Transparency is an experimental IETF (Internet Engineering Task Force) open standard which is used to monitor and audit digital certificates and to detect suspicious certificates and CAs within a reasonable time frame.


Functional Components


Certificate Transparency has three new functional components to the current SSL certificate system :

  • Certificate Log
  • Certificate Monitor
  • Certificate Auditor

Certificate Log


A Certificate Log is a simple network service that maintains a record of SSL certificates. Any interested entity can submit certificates to the Certificate Log, though it is expected that a CA or server operator submit a certificate to the log. A log is a single, ever growing and append only entity. When an interested party submits a valid digital certificate to the log, the log returns a Signed Certificate Timestamp or SCT. A valid digital certifcate can have a single valid SCT. So, if the log has seen the digital certificate before, it may return the same SCT which it has already returned before.


Anyone who gets a SCT of a certificate from a particular log, can verify it with the log. If there is any inconsistency, that would mean the certificate is compromised.

A Certificate Log is cryptographically assured. It uses a Merkle Hash Tree to maintain the log. A Merkle Hash Tree is a binary tree whose nodes are hashes of two child nodes. (More information on Merkle Tree can be found here : What is a Merkle Tree ? ) The Merkle Hash Tree of a log contains hashes of individual certificates in its leaves. And, every non-leaf node is a hash of its pair of child nodes. The root hash of the Merkle Tree is known as Merkle Tree Hash. The log server signs its Merkle Tree Hash with its secret key and it is known as Signed Tree Head or STH.


The Merkle Tree uses the hashing algorithm SHA-256. And, to sign various data structures, it uses elliptic curve signatures using NIST P-256 curve or RSA signatures using a key of at least 2048 bits.

So, to summarize, the input of the Merkle Hash Tree is a list of data entries or digital certificates. These data entries are hashed to form the leaves of the Merkle Tree. And, the output is a 32 byte Merkle Tree Hash.


Periodically, may be once in an hour, the log server appends all its newly submitted certificates to the log. Then, it creates a separate Merkle Tree Hash and combines it with the old Merkle Tree Hash. The new Merkle Tree Hash is then signed to create a new Signed Tree Head or STH. And, this process continues for all certificates ever submitted to the log.


The log also publishes a list of acceptable root certificates. A submitted certificate accompanies all the additional certificates required to verify the certificate chain up to required root certificate. When a TLS client receives a digital certificate along with SCT, it should verify the SCT with the signature input of SCT data and the certificate. They should also verify the signature with the log's public keys. If the log fails to provide a certificate with a valid SCT or presents multiple views of the Merkle Tree, that would indicate a security violation.


Monitor


Monitors are publicly run servers that periodically contact all the log servers to detect suspicious certificates. They watch the certificate logs and detect illegitimate or unauthorized certificates, unusual certificate extensions or certificate with strange permissions. They also make sure that the log certificates are visible to the log. Monitors periodically fetches entries from the log servers and monitors them.

To monitor the log certificates, the Monitors typically follow the steps below :

  • They fetch the Signed Tree Head or STH from the log.
  • They verify the STH signature.
  • They fetch all the entries in the tree corresponding to the STH.
  • They verify that the Merkle Tree constructed from the fetched entries produce the same hash as that of the STH.

Monitors are likely to be operated by CAs. They can also operate as standalone entities and provide services to the CAs and server operators. And, Monitors can be run by server operators like Google, Microsoft, Yahoo etc.

Auditor


An Auditor is a software component that fetches partial information from the log as input and verifies that the information is consistent. They can also verify that a particular certificate is present in the log.

An Auditor may be an integral component of a TLS client like browser. It may periodically send a batch of SCTs to its auditing component and verify the authenticity of the certificates. It asynchronously contact the logs and perform verification.

Basic operations of Certificate Transparency






So, to summarize, here is how Certificate Transparency operates :

  • Though anyone can submit a certificate to the log, it is expected that a CA or server operator submits a digital certificate. It is also possible for a CA to submit a certificate before its issuance.

    After submitting the certificate to the log, the log returns an SCT or Signed Certificate Timestamp and an MMD or Maximum Merge Delay. MMD indicates the time by which the certificate will be added to the log, so that the certificate can be issued within reasonable timeframe.
  • During TLS handshake, the TLS client receives the certificate along with the SCT and its signature chain.
  • TLS clients can use the SCT and the log to verify that the certificate is not misissued.
  • Please note that, the presence of SCT alone does not guarantee that the certificate is not misissued. The interested party must verify the SCT with the log.


Security


Misissued certificates that have not been publicly logged, will not have a valid SCT. So, the TLS client can detect its illegitimacy immediately.

TLS client can also verify the received SCT with the log. If there is any inconsistency, it will flag a security violation.

Interested party like domain owners can monitor the log and detect a misissue of a certificate. In fact, Certificate Transparency gives any interested party the opportunity to monitor and verify the integrity of the certificates.

The main advantage of Certificate Transparency is, it can detect a security violation within a few hours, instead of a few days, a few weeks or even a few months. And, this in turn speeds up the overall mitigation process in case of a misissue of a certificate.


Implementation of Certificate Transparency


Google launched Certificate Transparency log in March 2013. DigiCert is the first CA which has implemented Certificate Transparency. And now, Google Chrome requires Certificate Transparency for newly issued EV Certificates. ( What is EV Certificate ? )



The article was intended to give basic information on Certificate Transparency. Hope it solved the purpose.



Read More

What is Public Key Infrastructure and how can Blockchain be used there ?

 What is EV Certificate ?

 What are Smart Contracts ?



Posted by at

1 comment:

Subscribe to: Post Comments (Atom)