Certificate Transparency Logs Monitoring provides the key to more security
When digital certificates are issued by a certificate authority (CA), everything is based on trust in the CA that certificates will be issued correctly. However, the past has shown that this was not always the case. For example, certificates were issued with incorrect information, errors were made in the basic issuing of certificates, or a CA was used unnoticed by attackers to issue forged certificates. In order to maintain confidential communication on the Internet and to eliminate the above-mentioned sources of error, the Certificate Transparency Standard was created.
Certificate Transparency Standard delivers transparency
Certificate Transparency (CT) is intended to enable real-time monitoring of the certificates issued by CAs and make them publicly available. This means that incorrectly issued certificates or CAs that behave incorrectly can be identified more quickly, which means that countermeasures can be initiated more quickly.
Certificate Transparency provides for three components.
Component 1 – CT Logs
The CT standard stipulates that when a CA issues certificates (submit certificates), an entry is always made in a CT log. CT logs are network services that provide cryptographically secure and publicly accessible directories (public logs) of issued certificates. All entries can only be added and not deleted or edited (append only). Each Transparency Log has an interface through which entries can be added, queried, and cryptographic proofs can be performed. CT Logs are typically operated by CAs, Internet Service Providers (ISPs), or other parties of interest; currently there are 40 CT Log servers.
This is the first step towards increased security through increased transparency when CAs issue certificates (submit certificates). However, certificate forgery can only be detected if the CT logs are checked (certificate transparency monitoring).
Component 2 – Monitor
A monitor checks whether a false certificate has been issued (ct monitoring). This monitor retrieves new entries from the existing CT logs at certain intervals (log monitoring) and checks the information contained therein. Usually the monitor is offered in the form of a subscription service, where domain owners deposit their domain name and contact address and are notified by the monitor when a certificate has been issued for their domain.
Component 3 – Auditor
In order for the CT logs to add value to security, their correct behavior must be verified. This task is performed by the auditor. Basically, there are two types of cryptographic proof available to the auditor:
Consistency Proof is used to check the consistency of a CT log. This is used to verify that no entry in the tree structure used (hash tree) has been deleted, modified or inserted unnoticed and that the append only property is therefore satisfied. It is proven that the new hash tree was created after adding new entries from the union of the old hash tree with the new entries.
The procedure: Consistency proof is used to verify that all nodes of a previous version of a hash tree exist in the same order in the new tree before the new entries were added. For the execution, on the one hand nodes of the old tree are needed to calculate its hash value of the root node and on the other hand the hash values of the new nodes, which were created by adding new entries. The hash values of the nodes obtained from the CT log are then used to calculate the value of the root node of the new version of the tree. If the calculated value and the hash value of the root node presented by the log match, the new hash tree has been created from a previous version and its union with the tree of new entries. To obtain the hash values of the nodes needed for the calculation, the CT Log is passed the root hash value of the old tree and the new tree by the auditor.
Audit Proof can prove that an entry for a particular certificate exists in a CT Log. All nodes are required that are missing between the hash value of the entry being searched for and the root node. After obtaining the missing nodes, the hash value of the root node can be calculated and compared to the one provided by the CT Log. If the values match, the certificate being searched for is contained in the CT Log.
The procedure: To perform this cryptographic proof, the so-called audit path is used. This contains the smallest set of nodes needed to calculate the hash value of the root node of the tree, starting from the hash value of the searched entry. To obtain the audit path, the auditor passes the hash value of the entry whose existence he wants to prove in the log to the CT Log Server. If the hash value is not present in the log, the auditor receives an error message and no audit path. However, whether or not nodes are delivered by the log after a request is not proof that a log is working correctly. Therefore, the hash value of the root node must be calculated from the nodes contained in the audit path. Only if the calculated value matches the one presented by the log, it is proven that the entry in the log exists and no entry in the tree has been changed afterwards, so that the Append Only property of the CT log has been violated.
Log Monitoring with the help of essendi xc
The essendi xc certificate manager is a tool that enables the user to perform his certificate management in a fully automated way. This application has been extended by a log monitoring component. By integrating a log monitoring component, it is automatically possible to detect, revoke and revoke forged certificates in a timely manner. The CT Log Monitor not only sends warnings due to falsely issued certificates, but also info messages when certificates requested by the actual user have been entered into the CT logs. By implementing the Certificate Transparency Standard, the application thus provides significantly more security.