table of Contents
concept
Certificate transparent logs using special encryption algorithm contribute to public scrutiny certificates and logs. The particular encryption algorithm referred Merck hash tree (the Merkle the hash Tree) , comprising simple binary tree nodes and leaf hash (FIG. 1). The leaves are already attached to a single certificate log hash. Cotyledon node is paired hash or child node pairs. All root nodes and a leaf, i.e., the root hash referred Merck hash tree (the hash the Merkle Tree) . When the log server Merck tree hash (and other information) signature, called the signature tree head (STH: Signed Tree head) .
Periodically, probably once an hour, the newly acquired log server certificate appended to the log. Create a separate hash tree Merck newly acquired by the certificate, the hash and the hash tree Merck old previously combined into a new hash tree Merck (FIG. 2) in the hash tree. New Merck tree hash signature to create a new signature tree head. Repeatedly continued, before all certificates submitted to the log forms a growing Merck tree.
Audit certification and attestation of conformity
For such a configuration mode, Merck hash tree logs allow rapid and efficient prove two things:
- All certificates are consistently attached to the log
- Specific certificate attached to the log in
the log supports two encryption by providing proof: Merck and Merck proof to prove the consistency of audit.
Merck attestation of conformity
Merck consistency proof to verify a log of any of the two versions is the same: that is, the new version contains all the old version, in other words, keeping up with all the new entries after the last version of the entry. If it turns out the log is the same, meaning that no expired certificates and inserted into a log that no certificate has been modified, and the log does not branch too.
To demonstrate proof of principle Merck consistency, suppose you want to prove in Figures 2 and 3 log is the same. The first step, it is necessary to prove the old tree hash Merck Merck is a new subset of hash tree. And then prove that the new Merck Merck old tree hash is a hash tree node plus a hash of all the new additional intermediate certificate. Consistency proved calculated hash least intermediate nodes required for both sets.
In this case, the consistency of the intermediate node hash evidenced by: the k, l, and m(see FIG. 4). Use kand mcreate Merck old tree hash, and thus prove the existence of the old tree has not been changed. Then use land kcreate nwith nand mcreate a new log Merck tree hash. If the matching and the calculated hash tree Merck log, the log is consistent.
Regularly monitor and audit the use of consistency proof to verify whether the log normal. Because monitors and logs are usually the same as the certificate list may be self-consistent calculation proof, and verify the consistency of the log. Design simple query log server, to get any consistency proved the two signed a tree.
Merck audit certification
Merck audit certificates to verify that there is a particular certificate log. This is an important task of proof, transparent model because the certificate is required for all client TLS certificate does not refuse to appear in the log.
Merck audit to show proof of principle, suppose you want to verify d3certificate ( dleaves) already attached to the figure 3 in the log. Merck audit proved to be a lack of computing nodes needed to hash all of the nodes between the leaves and roots. If the computed hash and the root path of the audit log Merck current matches the hash tree, the tree leaves is present in (or in other words, the presence of the certificate in the log).
In this example, Merck audit certificates hash node comprising: c,i,n(see FIG. 5). That dknown, it can be ccalculated j. Then iand jcalculated m, then n, and mcalculate the hash tree log Merck. Similarly, if you want to verify that the certificate d4has been appended to the log, the log send you f, l, mattestation of conformity node hash. Leaves known hash ( e), it can be leaf hash fcalculated hash nodes k, then the node with the hash lcomputed hash nodes n, then the node hash mand nthe calculated log Merck tree Ha hope.
Anyone can request a log of Merck hash tree, a certificate can verify the existence of the log. Typically these types of audit requests sent to the log, so as to verify the certificate TLS client. If the audit proves Merck and Merck did not calculate the hash tree root hash match, it means that the certificate does not exist log.
Use of proven
Proven to provide encrypted data auditing needs. Notification, little is known about the audit log information, but in spite of limited knowledge, to prove whether it can verify the consistency and audit logs for a particular certificate has been attached to the log.
Without proof, the audit may access all logging or go back to the exercise of their duties. Let prove more efficient exchange of data, audit logs, and the amount of data exchange is also much less. For example, wrap 10 million certificate of logs needed only 24 nodes hash consistency proof. If the log increased to 20 million certificates, proof of the consistency of the number of nodes hash of it to 25.
Monitors also prove to be useful, although in slightly different ways. Monitors typically monitor to save a copy of the log, so that each certificate checking logs, and pay attention to a particular certificate. If the monitor checks to monitor the consistency of a particular log, it can be calculated to prove their identity, and then verifies the consistency of the log. Similarly, if the monitor specific certificate exists in the log always necessary, it is also their calculated audit certificates, certificate and then verify the proof.