Merkle<sup>2</sup>: A Low-Latency Transparency Log System

Hu, Yuncong; Hooshmand, Kian; Kalidhindi, Harika; Yang, Seung Jin; Popa, Raluca Ada

doi:10.1109/sp40001.2021.00088

Cited by 9 publications

(5 citation statements)

References 40 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It would be also interesting to apply efficient functional storage proof structures such as AAD [61], Merkle2 [62], and vector commitments [63,64] around blockchain to speed up certificate aggregation and verification times, as well as reduce proof size.…”

Section: Discussionmentioning

confidence: 99%

BRT: An Efficient and Scalable Blockchain-Based Revocation Transparency System for TLS Connections

Xing,

Wang,

et al. 2023

Sensors

View full text Add to dashboard Cite

Log-based public key infrastructure(PKI) refers to a robust class of CA-attack-resilient PKI that enhance transparency and accountability in the certificate revocation and issuance process by compelling certificate authorities (CAs) to submit revocations to publicly and verifiably accessible logs. However, log-based PKIs suffer from a reliance on centralized and consistent sources of information, rendering them susceptible to split-world attacks, and they regrettably fail to provide adequate incentives for recording or monitoring CA behavior. Blockchain-based PKIs address these limitations by enabling decentralized log audits through automated financial incentives. However, they continue to face challenges in developing a scalable revocation mechanism suited for lightweight clients. In this paper, we introduce BRT, a scalable blockchain-based system for certificate and revocation transparency. It serves to log, audit, and validate the status of certificates within the transport layer security (TLS)/secure sockets layer(SSL) PKI domain. We designed an audit-on-chain framework, coupled with an off-chain storage/computation system, to enhance the efficiency of BRT when operating in a blockchain environment. By implementing a blockchain-based prototype, we demonstrate that BRT achieves storage-efficient log recording with a peak compression rate reaching 8%, cost-effective log updates for large-scale certificates, and near-instantaneous revocation checks for users.

show abstract

Section: Discussionmentioning

confidence: 99%

BRT: An Efficient and Scalable Blockchain-Based Revocation Transparency System for TLS Connections

Xing,

Wang,

et al. 2023

Sensors

View full text Add to dashboard Cite

show abstract

“…Similarly, Wang et al [57] deeply integrated blockchain and CT to reinforce the security guarantees of certificates. Hu et al [23] introduced a novel transparency log system, called Merkle 2 , which offers efficient monitoring and low-latency updates. Dirksen et al [14] presented LogPicker to achieve mutual auditing amongst CT logs, thereby eliminating a trusted third party.…”

Section: Related Workmentioning

confidence: 99%

Certificate Transparency Revisited: The Public Inspections on Third-party Monitors

Sun,

Lin,

Wang

et al. 2024

Proceedings 2024 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

The certificate transparency (CT) framework has been deployed to improve the accountability of the TLS certificate ecosystem. However, the current implementation of CT does not enforce or guarantee the correct behavior of third-party monitors, which are essential components of the CT framework, and raises security and reliability concerns. For example, recent studies [32], [33] reported that 5 popular third-party CT monitors cannot always return the complete set of certificates inquired by users, which fundamentally impairs the protection that CT aims to offer. This work revisits the CT design and proposes an additional component of the CT framework, CT watchers. A watcher acts as an inspector of third-party CT monitors to detect any misbehavior by inspecting the certificate search services of a third-party monitor and detecting any inconsistent results returned by multiple monitors. It also semi-automatically analyzes potential causes of the inconsistency, e.g., a monitor's misconfiguration, implementation flaws, etc. We implemented a prototype of the CT watcher and conducted a 52-day trial operation and several confirmation experiments involving 8.26M unique certificates of about 6,000 domains. From the results returned by 6 active thirdparty monitors in the wild, the prototype detected 14 potential design or implementation issues of these monitors, demonstrating its effectiveness in public inspections on third-party monitors and the potential to improve the overall reliability of CT.

show abstract

“…The append-only log should provide integrity: once an entry is added, it cannot be altered or deleted. This log could be implemented as a permissioned ledger [6,8] or a centrally maintained log that permits public auditing [5,16,22,41,51,58,73,74]; the only requirement is that the log itself does not become a central point of attack.…”

Section: Building Blocksmentioning

confidence: 99%

Reflections on trusting distributed trust

Dauterman,

Fang,

Crooks

et al. 2022

Preprint

View full text Add to dashboard Cite

Many systems today distribute trust across multiple parties such that the system provides certain security properties if a subset of the parties are honest. In the past few years, we have seen an explosion of academic and industrial cryptographic systems built on distributed trust, including secure multi-party computation applications (e.g., private analytics, secure learning, and private key recovery) and blockchains. These systems have great potential for improving security and privacy, but face a significant hurdle on the path to deployment. We initiate study of the following problem: a single organization is, by definition, a single party, and so how can a single organization build a distributed-trust system where corruptions are independent? We instead consider an alternative formulation of the problem: rather than ensuring that a distributed-trust system is set up correctly by design, what if instead, users can audit a distributed-trust deployment? We propose a framework that enables a developer to efficiently and cheaply set up any distributed-trust system in a publicly auditable way. To do this, we identify two application-independent building blocks that we can use to bootstrap arbitrary distributed-trust applications: secure hardware and an append-only log. We show how to leverage existing implementations of these building blocks to deploy distributed-trust systems, and we give recommendations for infrastructure changes that would make it easier to deploy distributed-trust systems in the future. CCS Concepts• Security and privacy → Distributed systems security;

show abstract

Merkle²: A Low-Latency Transparency Log System

Cited by 9 publications

References 40 publications

BRT: An Efficient and Scalable Blockchain-Based Revocation Transparency System for TLS Connections

BRT: An Efficient and Scalable Blockchain-Based Revocation Transparency System for TLS Connections

Certificate Transparency Revisited: The Public Inspections on Third-party Monitors

Reflections on trusting distributed trust

Contact Info

Product

Resources

About

Merkle2: A Low-Latency Transparency Log System

Cited by 9 publications

References 40 publications

BRT: An Efficient and Scalable Blockchain-Based Revocation Transparency System for TLS Connections

BRT: An Efficient and Scalable Blockchain-Based Revocation Transparency System for TLS Connections

Certificate Transparency Revisited: The Public Inspections on Third-party Monitors

Reflections on trusting distributed trust

Contact Info

Product

Resources

About

Merkle²: A Low-Latency Transparency Log System