Verifiable Light-Weight Monitoring for Certificate Transparency Logs

11/10/2017
by   Rasmus Dahlberg, et al.
0

Trust in publicly verifiable Certificate Transparency (CT) logs is reduced through cryptography, gossip, auditing, and monitoring. The role of a monitor is to observe each and every log entry, looking for suspicious certificates that interest the entity running the monitor. While anyone can run a monitor, it requires continuous operation and copies of the logs to be inspected. This has lead to the emergence of monitoring-as-a-service: a trusted party runs the monitor and provides registered subjects with selective certificate notifications, e.g., "notify me of all foo.com certificates". We present a CT/bis extension for verifiable light-weight monitoring that enables subjects to verify the correctness of such notifications, reducing the trust that is placed in these monitors. Our extension supports verifiable monitoring of wild-card domains and piggybacks on CT's existing gossip-audit security model.

READ FULL TEXT VIEW PDF

Authors

page 1

page 2

page 3

page 4

03/03/2022

Postcertificates for Revocation Transparency

The modern Internet is highly dependent on trust communicated via certif...
01/13/2020

Characterizing the Root Landscape of Certificate Transparency Logs

Internet security and privacy stand on the trustworthiness of public cer...
09/21/2018

The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem

In this paper, we analyze the evolution of Certificate Transparency (CT)...
06/23/2021

Finding Phish in a Haystack: A Pipeline for Phishing Classification on Certificate Transparency Logs

Current popular phishing prevention techniques mainly utilize reactive b...
06/22/2018

Aggregation-Based Gossip for Certificate Transparency

Certificate Transparency (CT) is a project that mandates public logging ...
03/03/2022

SoK: SCT Auditing in Certificate Transparency

The Web public key infrastructure is essential to providing secure commu...
07/25/2020

Efficient Two-Layered Monitor for Partially Synchronous Distributed Systems (Technical Report)

Monitoring distributed systems to ensure their correctness is a challeng...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Certificate Transparency (CT) [12] is an experimental standard that enhances the public-key infrastructure by adding transparency for certificates that are issued by Certificate Authorities (CAs). The idea is to mandate that every certificate must be publicly logged in an append-only tamper-evident data structure [2], such that anyone can observe what has been issued for whom. This means that a subject can determine for herself if anything is mis-issued by downloading all certificates; so called self-monitoring. An alternative monitoring approach is to rely on a trusted third-party that notifies the subject if relevant certificates are ever found. Given that self-monitoring involves set-up, continuous operation, and exhaustive communication effort, the concept of subscribing for monitoring as-a-service is simpler for the subject. This model is already prevalent in the wild, and is provided both by CAs and industry vendors—see for example SSLMate’s Cert Spotter111https://sslmate.com/certspotter/, accessed 2018-09-15. or Facebook’s monitoring tool222https://developers.facebook.com/tools/ct/, accessed 2018-09-15. . Third-party monitors can also offer related services, such as searching for certificates interactively or inspecting other log properties. The former is provided by Facebook and Comodo’s crt.sh; the latter by Graham Edgecombe’s CT monitoring tool333https://ct.grahamedgecombe.com/, accessed 2018-09-15. .

It would be an unfortunate short-coming if CT did not change the status quo of centralized trust by forcing subjects who cannot operate a self-monitor to trust certificate notifications that are provided by a third-party monitor. While it is true that a subject could subscribe to a large number of monitors to reduce this trust, it is overall cumbersome and does not scale well beyond a handful of notifying monitors (should they exist). To this end, we suggest a CT/bis extension for verifiable Light-Weight Monitoring (LWM) that makes it easier to distribute the trust which is otherwise placed in these monitors by decoupling the notifier from the full-audit function of inspecting all certificates. Our idea is best described in terms of a self-monitor that polls for new updates, but as opposed to processing all certificates we can filter on wild-card prefixes such as *.example.com in a verifiable manner. LWM relies on the ability to define a new Signed Tree Head (STH) extension, and thus a CT/bis compliant log is necessary [13]. At the time of writing CT/bis have yet to be published as an IETF standard. We are not aware of any log that deploys a drafted version.

As a brief overview, each batch of newly included certificates are grouped as a static Merkle tree in LWM. The resulting snapshot (also know as a fingerprint or a root hash) is then incorporated into the corresponding STH as an extension. An LWM subject receives one verifiable certificate notification per log update from an untrusted notifier (who could be the log, a monitor, or anyone else), and this notification is based on the smaller static Merkle tree rather than the complete log. This is because monitoring as-a-service is mainly about identifying newly included certificates. Moreover, we can order each static Merkle tree so that verifiable wild-card filtering is possible. For security we rely on at least one entity to verify that each snapshot is correct—which is a general monitoring function that is independent of the subjects using LWM—as well as a gossip protocol that detects split-views [1]. Since our extension is part of an STH, we piggyback on any gossip-like protocol that deals with the exchange and/or distribution of (verified) STHs [4, 16, 18, 19]. Our contributions are as follows:

  • The design of a backwards-compatible CT/bis extension for light-weight monitoring of wild-card prefixes such as *.example.com (Section 3).

  • A security sketch showing that an attacker cannot omit a certificate notification without being detected, relying on standard cryptographic assumptions and piggybacking on the proposed gossip-audit models of CT (Section 4.1).

  • An open-source proof-of-concept implementation written in Go, as well as a performance evaluation that considers computation time and bandwidth requirements (Section 4.2). In particular we find that the overhead during tree head construction is small in comparison to a sound STH frequency of one hour; a notifier can easily notify 288 M subjects in a verifiable manner for Google’s Icarus log on a single core and a 1 Gbps connection; and a subject receives about 24 Kb of proofs per day and log which is verified in negligible time (the order of s for the common case of non-membership, and seconds in the extreme case of verifying membership for an entire top-level domain).

Background on Merkle trees and CT is provided in Section 2. Related work is discussed in Section 4.3. Conclusions are presented in Section 5.

2 Background

Suppose that a trusted content provider would like to outsource its operation to an untrusted third-party. This is often referred to as the three-party setting, in which a trusted source maintains an authenticated data structure through a responder that answers client queries on the source’s behalf [20]. The data structure is authenticated in the sense that every answer is accompanied by a cryptographic proof that can be verified for correctness by only trusting the source. While there are many settings and flavors of authenticated data structures [2, 3, 5], our scope is narrowed down to CT which builds upon Merkle trees.

2.1 Merkle Trees

The seminal work by Merkle [15] proposed a static binary tree where each leaf stores the hash of a value and every interior node hashes its children (Figure 1). The root hash serves as a succinct snapshot of the tree’s structure and content, and by revealing a logarithmic number of hashes it can be reconstructed to prove whether a value is stored in a leaf. These hashes compose an audit path for a value, and it is obtained by taking every sibling hash while traversing the tree from the root down towards the leaf being authenticated. An audit path is verified by reversing the traversal used during generation, first reconstructing the leaf hash and then every interior node recursively (using the provided sibling hashes) until finally reaching the root. Given a collision resistant hash function, an audit path proves that a given leaf contains a value iff the reconstructed root hash is known to be authentic. For example, the trusted source might sign it.

Figure 1: Merkle tree containing four values . The dashed arrows show the traversal used to generate an audit path for the right-most leaf (dashed nodes).

While non-membership of a value can be proven by providing the entire data structure, this is generally too inefficient since it requires linear space and time. A better approach is to structure the tree such that the node which should contain a value is known if it exists. This property is often discussed in relation to certificate revocation: as opposed to downloading a list of serial numbers that represent the set of revoked certificates, each leaf in a static Merkle tree could (for example) contain an interval where is revoked and the open interval current [11]. Given a serial number , an audit path can be generated in logarithmic space and time for the leaf where to prove (non-)membership. Similar constructions that are dynamic support updates more efficiently [3, 7, 14].

2.2 Certificate Transparency

The CA ecosystem involves hundreds of trusted third-parties that issue TLS certificates [6]. Once in a while somebody gets this process wrong, and as a result a fraudulent identity-to-key binding may be issued for any subject [8]. It is important to detect such incidents because mis-issued certificates can be used to intercept TLS connections. However, detection is hard unless the subjects who can distinguish between anything benign and fraudulent get a concise view of the certificates that are being served to the clients. By requiring that every CA-issued certificate must be disclosed in a public and append-only log, CT layers on-top of the error-prone CA ecosystem to provide such a view: in theory anyone can inspect a log and determine for herself if a certificate is mis-issued [12].

It would be counter-intuitive to ‘solve’ blind trust in CAs by suggesting that everybody should trust a log. Therefore, CT is designed such that the log can be distrusted based on two components: a dynamic append-only Merkle tree that supports verifiable membership and consistency queries [2], as well as a gossip protocol that detects split-views [1, 16]. We already introduced the principles of membership proofs in Section 2.1, and consistency proofs are similar in that a logarithmic number of hashes are revealed to prove two snapshots consistent. In other words, anyone can verify that a certificate is included in the log without fully downloading it, and whatever was in the log before still remains unmodified. Unlike the three-party setting, gossip is needed because there is no trusted source that signs-off the authenticated data structure: consistency and inclusion proofs have limited value if everybody observes different (but valid) versions of the log.

2.2.1 Terminology, policy parameters and status quo.

A new STH—recall that this is short for Signed Tree Head—is issued by the log at least every Maximum Merge Delay (MMD) and no faster than allowed by an STH frequency [13]. An MMD is the longest time until a certificate must be included in the log after promising to include it. This promise is referred to as a Signed Certificate Timestamp (SCT). An STH frequency is relative to the MMD, and limits the number of STHs that can be issued. These parameters (among others) are defined in a log’s policy, and if a violation is detected there are non-repudiable proofs of log misbehavior that can be presented. For example, show an SCT that is not included after an MMD, too many STHs during the period of an MMD, or two STHs that are part of two inconsistent versions of the log. In other words, rather than being a trusted source a log signs statements to be held accountable.

Ideally we would have all of these components in place at once: anyone that interacts with a log audits it for correctness based on partial information (SCTs, STHs, served certificates, and proofs), subjects monitor the logs for newly included certificates to check that they are free from mis-issuance (full download), and a gossip protocol detects or deters logs from presenting split-views. This is not the case in practice, mainly because CT is being deployed incrementally [18] but also because the cost and complexity of self-monitoring is relatively high. For example, a subject that wants rapid detection of mis-issuance needs continuous operation and full downloads of the logs. It appears that the barrier towards self-monitoring have lead to the emergence of monitoring as-a-service, where a trusted third-party monitors the logs on a subject’s behalf by selectively notifying her of relevant certificates, e.g., mail the operator of if certificates are ever found. Third-party monitoring is convenient for logs too because it reduces the bandwidth required to serve many subjects. However, for CT it is an unintuitive concept given that it requires blind trust.

3 Light-Weight Monitoring

To reduce the trust which is placed in today’s third-party monitors, the idea of LWM is to lower the barrier towards self-monitoring. As shown in Figure 2, an untrusted notifier provides a subject with efficient444Efficient iff less than a linear number of log entries are received per log update. certificate notifications that can be cryptographically verified: each batch of certificates is represented by an additional Merkle tree that supports wild-card (non-)membership queries (described further in Section 3.1), and the resulting snapshot is signed by the log as part of an STH extension. As such, a subject can deal only with those certificates that are relevant, relying on wild-card proofs to verify correctness and completeness: said certificates are included and nothing is being omitted. Anyone can check that an LWM snapshot is correct by inspecting the corresponding batch of certificates. Notably this is a general monitoring function, rather than a selective notification component which is verifiable in LWM. This decoupling allows anyone to be a notifier, including logs and monitors that a subject distrust.

Log

Subject

Notifier

Monitor

STH with snapshot extension

verify STH extension

verify notification

optional verify

batch, STH

notification

batch, STH
Figure 2: An overview of LWM. In addition to normal operation, a log creates an additional (smaller) Merkle tree that supports wild-card (non-)membership queries. The resulting snapshot is signed as part of an STH extension that can be verified by any monitor that downloads the corresponding batch. A subject receives one verifiable certificate notification per STH from an untrusted notifier.

3.1 Authenticated Wild-Card Queries

Thus far we only discussed Merkle trees in terms of verifying whether a single value is a (non-)member: membership is proven by presenting an audit path down to the leaf in question, while non-membership requires a lexicographical ordering that allows a verifier to conclude that a value is absent unless provided in a particular location. The latter concept naturally extends to prefix wild-card queries—such as and —by finding a suitable ordering function which ensures that related leaves are grouped together as a consecutive range. We found that this requirement is satisfied by sorting on reversed subject names: suppose that we have a batch of certificates , , , and . After applying we get the static Merkle tree in Figure 3. A prefix wild-card proof is constructed by finding the relevant range in question, generating an audit path for the leaves that are right outside of the range [17]. Such a proof is verified by checking that (i) indicates that the left (right) end is less (larger) than the queried prefix, (ii) the leaves are ordered as dictated by , and (iii) the recomputed root hash is valid.

Figure 3: Merkle tree where the leaves are ordered on reversed subject names.

The exact details of reconstructing the root hash is a bit tedious because there are several corner cases. For example, either or both of the two audit paths may be empty depending on batch size () and location of the relevant range (left/right-most side). Therefore, we omit the details and focus on the concept: given two audit paths and a sequence of data items ordered by that includes the left leaf, matching range, and right leaf, repeatedly reconstruct interior nodes to the largest extent possible and then use the sibling hash which is furthest from the root to continue. For example, consider a proof for in Figure 3: it is composed of (i) the left leaf data and its audit path on index 1, (ii) the right leaf data and its audit path on index 3, and (iii) the matching range itself which is a single certificate. After verifying  order, recompute the root hash and check if it matches an authentic root as follows:

  1. Compute leaf hashes , , and from the provided data. Next, compute the interior node . Because no additional interior node can be computed without a sibling hash, consider in the left audit path.

  2. Compute the interior node , then finally .555Two audit paths may contain redundancy, but we ignored this favouring simplicity.

Given an  ordered list of certificates it is trivial to locate where a subject’s wild-card matches are: binary search to find the index of an exact match (if any), then up to matches follow in order. This is not the only way to find the right range and matches. For example, a radix tree could be used with the main difference being against complexity for a batch of size , a wild-card string of length , and matches. Since the complexity of generating two audit paths is for any number of matches, the final space and time complexity for a wild-card structure based on an ordered list is .

3.2 Notifier

A notifier must obtain every STH to generate wild-card proofs that can be traced back to the log. Albeit error-prone in case of network issues, the simplest way to go about this is to poll the log’s get-STH endpoint frequently enough.666It would be better if logs supported verifiable and historical get-STH queries. Once an updated is spotted every new certificate is downloaded and the wild-card structure is reconstructed. A subject receives her verifiable certificate notifications from the notifier via a push (‘monitoring as-a-service’) or pull (‘self-monitoring’) model. For example, emails could be delivered after every update or in daily digests. Another option is to support queries like “what’s new since STH ”.

A subject can verify that a certificate notification is fresh by inspecting the STH timestamp. However, it is hard to detect missing certificate notifications unless every STH trivially follows from the previous one. While there are several methods to achieve this—for example using indices (Section 3.3) or hash chains [14]—the log must always sign a snapshot per STH using an extension.

3.3 Instantiation Example

Instantiating LWM depends upon the ability to support an STH extension. In the latest version of CT, this takes the form of a sorted list of key-value pairs where the key is unique and the value an opaque byte array [13]. We could reserve the keywords lwm for snapshots and index for monotonically increasing counters.777Instead of an index to detect missing notifications (STHs), a log could announce STHs as part of a verifiable get-STH endpoint. See the sketch of Nordberg: https://web.archive.org/web/20170806160119/https://mailarchive.ietf.org/arch/msg/trans/JbFiwO90PjcYzXrEgh-Y7bFG5Fw, accessed 2018-09-16. Besides an LWM-compliant log, an untrusted notifier must support pushed or pulled certificate notifications that are verifiable by tracking the most recent or every wild-card structure. Examples of likely notifiers include logs (who benefit from the reduced bandwidth) and monitors (who could market increased transparency) that already process all certificates regardless of LWM.

4 Evaluation

First we discuss assumptions and sketch on relevant security properties for LWM. Next, we examine performance properties of our open-source proof-of-concept implementation experimentally and reason about bandwidth overhead in theory. Finally, we present differences and similarities between LWM and related work.

4.1 Assumptions and Security Notions

The primary threat is a computationally bound attacker that attempts to forge or omit a certificate notification without being detected. We rely on standard cryptographic assumptions, namely an unforgeable digital signature scheme and a collision resistant hash function with -bit output for a security parameter . The former means that an LWM snapshot must originate from the (untrusted) log in question. While an incorrect snapshot could be created intentionally to hide a mis-issued certificate, it would be detected if at least one honest monitor exists because our STH extension piggybacks on the gossip-audit model of CT (that we assume is secure).888Suppose that witness cosigning is used [19]. Then we rely on at least one witness to verify our extension. Or, suppose that STH pollination is used [16]. Then we rely on the most recent window of STHs to reach a monitor that verifies our extension. A subject can further detect missing notifications by checking the STH index for monotonic increases and the STH timestamp for freshness. Thus, given secure audit paths and correct verification checks as described in Section 3.1, no certificate notification can be forged or omitted. Our cryptographic assumptions ensure that every leaf is fixed by a secure audit path as in CT, i.e., a leaf hash with value is encoded as ) and an interior hash with children as  [2, 12]. To exclude any unnecessary data on the ends of a range, the value is a subject name concatenated with a hashed list of associated certificates in LWM (subject names suffice to verify  order).

CT makes no attempt to offer security in the multi-instance setting [9]. Here, an attacker that targets many different Merkle trees in parallel should gain no advantage while trying to forge any valid (non-)membership proof. By design there will be many different wild-card Merkle trees in LWM, and so the (strictly stronger) multi-instance setting is reasonable. We can provide full bit-security in this setting by ensuring that no node’s pre-image is valid across different trees by incorporating a unique tree-wide constant in leaf and empty hashes per batch, e.g., . Melera et al. [14] describe this in detail while also ensuring that no node’s pre-image is valid across different locations within a Merkle tree.

In an ecosystem where CT is being deployed incrementally without gossip, the benefit of LWM is that a subject who subscribes for certificate notifications can trust the log only (as opposed to also trusting the notifier). Therefore, today’s trust in third-party monitoring services can be reduced significantly. A log must also present a split-view or an invalid snapshot to deceive a subject with false notifications. As such, subjects accumulate binding evidence of log misbehavior that can be audited sometime in the future if suspicion towards a log is raised. Long-term the benefit of LWM is that it is easier to distribute the trust which is placed in third-party monitors, i.e., anyone who processes a (small in comparison to the entire log) batch of certificates can full-audit it without being a notifier.

4.2 Implementation and Performance

We implemented multi-instance secure LWM in less than 400 lines of Go.999Open source implementation available at https://github.com/rgdd/lwm. Our wild-card structure uses an existing implementation of a radix tree to find leaf indices and data. To minimize proof-generation times, all hashes are cached in an in-memory Merkle tree which uses SHA-256. We benchmarked snapshot creation, proof generation, and proof verification times on a single core as the batch size increases from 1024–689,245 certificates using Go’s built-in benchmarking tool, an Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, and 2x8 Gb DDR3 RAM. We assumed real subject names from Alexa’s top-1M101010http://s3.amazonaws.com/alexa-static/top-1m.csv.zip, accessed 2018-08-05. and average-sized certificates of 1500 bytes111111https://www.grahamedgecombe.com/blog/2016/12/22/compressing-x509-certificates, accessed 2018-08-15. , where a batch of subject names refers to the most popular domains. Notably 689,245 certificates is the largest batch observed by us in Google’s Icarus log between 2017-01-25 and 2018-08-05, corresponding to an STH interarrival time of 27.1 hours. The median (average) batch size and STH interarrival time were 22818 (23751) certificates and 60.1 (61.6) minutes. Only two batches were larger than 132077 certificates. Considering that Icarus is one of the logs that see largest loads,121212https://sslmate.com/labs/ct_growth/, accessed 2018-08-15. we can make non-optimistic conclusions regarding the performance overhead of LWM without inspecting other logs.

Figure 4 shows snapshot creation time as a function of batch size. Nearby the median () it takes 0.39 seconds to create a snapshot from scratch, initializing state from an unordered dictionary and caching all hashes for the first time. For the largest batch, the snapshot creation time is roughly 10 seconds. Arguably this overhead is still insignificant for logs, monitors, and notifiers because the associated STH interarrival times are orders of magnitude larger.

Figure 4: Snapshot creation time as a function of batch size.

Figure 5 shows proof generation time as a function of batch size while querying for the longest wild-card prefix with a single match (membership), as well as another wild-card prefix without any match in com’s top-level domain (non-membership). There is little or no difference between the generation time for these types of wild-card proofs, and nearby the median it takes around 7 . For the largest batch, this increased to  . A notifier can thus generate 288 million non-membership notifications per hour on a single core. Verification is also in the order of , which should be negligible for a subject (see Figure 6).

Figure 5: Membership and non-membership proof query time as a function of batch size for a single and no match, respectively.
Figure 6: Membership and non-membership verification time as a function of batch size for a single and no match, respectively.

To evaluate the cost of generating and verifying a wild-card notification with a large number of matches, we queried for com’s entire top-level domain (see Figure 7). In the largest batch where there are 352,383 matches, the proof generation time is still relatively low: 134 ms. This corresponds to 28.9k notifications per hour on a single core. The verification time is much larger: 3.5 seconds. This is expected since verification involves reconstructing the root from all the matching leaves, which is at least as costly as creating a snapshot of the same size (cf.  in Figure 4). While these are relevant performance numbers, anyone who is interested in a top-level domain would likely just download the entire batch.

Figure 7: Membership query and verification time for .

Finally, the space overhead of a verifiable wild-card notification is dominated by the two audit paths that enclose the matching subject names. Given that an audit path contains at most sibling hashes for a batch of size , the median overhead is roughly one Kb per STH, log, and LWM subject. Viewed from the perspective of a self-monitor, this is a significant bandwidth improvement: as opposed to downloading the median batch of 32.6 Mb, one Kb and any matching certificate(s) suffice. In the case of multiple logs, the bandwidth improvement is even greater. For the notifier we already established that it is relatively cheap to generate new notifications. Namely, in the single-core case of 288 M notifications per hour the bandwidth overhead would be 640 Mbs (i.e., all proofs must be distributed before the next STH is issued). A notifier can thus notify for a dozen of logs and a significant amount of LWM subjects without running into any CPU or bandwidth restrictions. Notably this is under the assumption of a sound STH frequency—one hour in our evaluation, as used by Icarus and many other logs.

4.3 Related Work

Earlier work related to transparent certificate and key management often use dynamic authenticated dictionaries [3, 5, 7, 10]. CONIKS maps a user’s mail address to her public key in a binary Merkle prefix tree, and after each update a client self-monitors her own key-binding by fetching an exact-match (non-)membership proof [14]. While our work is conceptually similar to CONIKS since a subject receives one (non-)membership proof per log update, the main difference is that LWM builds a new Merkle tree for each update in which wild-card queries are supported. This idea is inapplicable for CONIKS because a user is potentially interested in the public key of any mail address (hence the ability to query the entire data structure on an exact-match). CONIKS is similarly inapplicable for self-monitors in CT because a subject cares about wild-card queries and new certificates. Without the need for wild-cards, any authenticated dictionary could be used as a batch building block to instantiate LWM. While a radix tree viewed as a Merkle tree131313https://github.com/ethereum/wiki/wiki/Patricia-Tree, accessed 2018-08-15. could support efficient wild-card proofs, it is more complex than necessary. Therefore, we built upon the work of Kocher [11] and Nuckolls [17] with a twist on how to group the data for a new use-case: LWM.

5 Conclusion

We proposed a backwards-compatible CT/bis extension that enables light-weight monitoring (in short LWM). At the cost of a few hundred Kb per day, a subject can either self-monitor or subscribe to verifiable certificate notifications for a dozen of logs via an untrusted notifier. The security of LWM piggybacks on the gossip-audit model of CT, and it relies only on the existence of at least one honest monitor that verifies our extension. The cost of a compliant log is overhead during the tree head construction, and this overhead is insignificant in comparison to a log’s STH frequency. A notifier can generate verifiable certificate notifications—even for wild-card queries for all domains under a top-level domain—in the order of milliseconds on a single core. Given an STH frequency of one hour and 288 M LWM subjects, the incurred bandwidth overhead is roughly 640 Mbps for proofs. As such, a log could easily be its own notifier on a 1 Gbps connection. Further, any willing third-party could notify for a dozen of logs on a 10 Gbps connection.

5.0.1 Acknowledgments.

We would like to thank Linus Nordberg for value feedback. This research was funded by the Swedish Knowledge Foundation as part of the HITS research profile.

References

  • [1] Chuat, L., Szalachowski, P., Perrig, A., Laurie, B., Messeri, E.: Efficient gossip protocols for verifying the consistency of certificate logs. In: IEEE Conference on Communications and Network Security (CNS). pp. 415–423 (Septemper 2015)
  • [2] Crosby, S.A., Wallach, D.S.: Efficient data structures for tamper-evident logging. In: 18th USENIX Security Symposium. pp. 317–334 (August 2009)
  • [3] Crosby, S.A., Wallach, D.S.: Authenticated dictionaries: Real-world costs and trade-offs. ACM Transactions on Information and System Security (TISSEC) 14(2), 17:1–17:30 (September 2011)
  • [4] Dahlberg, R., Pulls, T., Vestin, J., Høiland-Jørgensen, T., Kassler, A.: Aggregation-based gossip for certificate transparency. CoRR abs/1806.08817 (August 2018)
  • [5] Derler, D., Hanser, C., Slamanig, D.: Revisiting cryptographic accumulators, additional properties and relations to other primitives. In: Topics in Cryptology—Proceedings of the Cryptographer’s Track at the RSA Conference (CT-RSA). pp. 127–144 (April 2015)
  • [6] Durumeric, Z., Kasten, J., Bailey, M., Halderman, J.A.: Analysis of the HTTPS certificate ecosystem. In: Proceedings of the 2013 Internet Measurement Conference. pp. 291–304 (October 2013)
  • [7] Eijdenberg, A., Laurie, B., Cutter, A.: Verifiable data structures. Google research document (November 2015), https://github.com/google/trillian/blob/master/docs/VerifiableDataStructures.pdf, accessed 2018-09-16
  • [8] ENISA: Certificate authorities—the weak link of Internet security. Info notes (September 2016), https://web.archive.org/web/20180527220047/https://www.enisa.europa.eu/publications/info-notes/certificate-authorities-the-weak-link-of-internet-security, accessed 2018-09-16
  • [9] Katz, J.: Analysis of a proposed hash-based signature standard. In: Third International Conference on Security Standardisation Research (SSR). pp. 261–273 (December 2016)
  • [10] Kim, T.H., Huang, L., Perrig, A., Jackson, C., Gligor, V.D.: Accountable key infrastructure (AKI): A proposal for a public-key validation infrastructure. In: 22nd International World Wide Web Conference (WWW). pp. 679–690 (May 2013)
  • [11] Kocher, P.C.: On certificate revocation and validation. In: Proceedings of the Second International Conference on Financial Cryptography (FC). pp. 172–177 (February 1998)
  • [12] Laurie, B., Langley, A., Kasper, E.: Certificate transparency. RFC 6962, IETF (June 2013), https://tools.ietf.org/html/rfc6962
  • [13] Laurie, B., Langley, A., Kasper, E., Messeri, E., Stradling, R.: Certificate transparency version 2.0. Internet-draft draft-ietf-trans-rfc6962-bis-28, IETF (March 2018), https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-28, work in progress
  • [14] Melara, M.S., Blankstein, A., Bonneau, J., Felten, E.W., Freedman, M.J.: CONIKS: Bringing key transparency to end users. In: 24th USENIX Security Symposium. pp. 383–398 (August 2015)
  • [15] Merkle, R.C.: A digital signature based on a conventional encryption function. In: Advances in Cryptology (CRYPTO). pp. 369–378 (August 1987)
  • [16] Nordberg, L., Gillmor, D.K., Ritter, T.: Gossiping in CT. Internet-draft draft-ietf-trans-gossip-05, IETF (January 2018), https://tools.ietf.org/html/draft-ietf-trans-gossip-05, work in progress
  • [17] Nuckolls, G.: Verified query results from hybrid authentication trees. In: Proceedings of the 19th Annual IFIP WG 11.3 Working Conference on Data and Applications Security. pp. 84–98 (August 2005)
  • [18] Sleevi, R., Messeri, E.: Certificate transparency in Chrome: Monitoring CT logs consistency. Design document, Google Inc. (March 2017), https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1, accessed 2018-09-16
  • [19] Syta, E., Tamas, I., Visher, D., Wolinsky, D.I., Jovanovic, P., Gasser, L., Gailly, N., Khoffi, I., Ford, B.: Keeping authorities “honest or bust” with decentralized witness cosigning. In: IEEE Symposium on Security and Privacy (SP). pp. 526–545 (May 2016)
  • [20] Tamassia, R.: Authenticated data structures. In: 11th Annual European Symposium (ESA) on Algorithms. pp. 2–5 (September 2003)