Biblio

Certificate Authorities (CAs) are important components for digital certificate issuances in Public Key Infrastructure(PKI). However, current CAs have some intrinsic weaknesses due to the CA-centric implementation. And when browser and operating system vendors contain a CA in the software, they place complete trust in the CA. In this paper, we utilize natural characteristics of tamper-proof and transparency of smart contracts in blockchain platforms to design an independent entity, named the CA proxy, to manage life cycle of digital certificates. This management will achieve the certificate transparency. We propose a new system architecture easy to integrate the CA proxy with current CAs through applying the blockchain oracle service. In this architecture, the CA proxy, CAs, and even professional identity verification parties can accomplish life cycle management of certificates, signature of certificates, identity verification for certificates correspondingly. The achievement of the certificate transparency through life cycle management of digital certificates in blockchain platforms, when compared with traditional CAs, solves traditional CAs' trust model weaknesses and improve the security.

Certificate Transparency (CT) is an emerging system for enabling the rapid discovery of malicious or misissued certificates. Initially standardized in 2013, CT is now finally beginning to see widespread support. Although CT provides desirable security benefits, web browsers cannot begin requiring all websites to support CT at once, due to the risk of breaking large numbers of websites. We discuss challenges for deployment, analyze the adoption of CT on the web, and measure the error rates experienced by users of the Google Chrome web browser. We find that CT has so far been widely adopted with minimal breakage and warnings. Security researchers often struggle with the tradeoff between security and user frustration: rolling out new security requirements often causes breakage. We view CT as a case study for deploying ecosystem-wide change while trying to minimize end user impact. We discuss the design properties of CT that made its success possible, as well as draw lessons from its risks and pitfalls that could be avoided in future large-scale security deployments.

Accountability is a recent paradigm in security protocol design which aims to eliminate traditional trust assumptions on parties and hold them accountable for their misbehavior. It is meant to establish trust in the first place and to recognize and react if this trust is violated. In this work, we discuss a protocol-agnostic definition of accountability: a protocol provides accountability (w.r.t. some security property) if it can identify all misbehaving parties, where misbehavior is defined as a deviation from the protocol that causes a security violation. We provide a mechanized method for the verification of accountability and demonstrate its use for verification and attack finding on various examples from the accountability and causality literature, including Certificate Transparency and Krollˆ\textbackslashtextbackslashprimes Accountable Algorithms protocol. We reach a high degree of automation by expressing accountability in terms of a set of trace properties and show their soundness and completeness.

In this paper, we analyze the evolution of Certificate Transparency (CT) over time and explore the implications of exposing certificate DNS names from the perspective of security and privacy. We find that certificates in CT logs have seen exponential growth. Website support for CT has also constantly increased, with now 33% of established connections supporting CT. With the increasing deployment of CT, there are also concerns of information leakage due to all certificates being visible in CT logs. To understand this threat, we introduce a CT honeypot and show that data from CT logs is being used to identify targets for scanning campaigns only minutes after certificate issuance. We present and evaluate a methodology to learn and validate new subdomains from the vast number of domains extracted from CT logged certificates.

In past, several Certificate Authority (CA) compromise and subsequent mis-issue of certificate raise the importance of certificate transparency and dynamic trust management for certificates. Certificate Transparency (CT) provides transparency for issued certificates, thus enabling corrective measure for a mis-issued certificate by a CA. However, CT and existing mechanisms cannot convey the dynamic trust state for a certificate. To address this weakness, we propose Smart Contract-assisted PKI (SCP) - a smart contract based PKI extension - to manage dynamic trust network for PKI. SCP enables distributed trust in PKI, provides a protocol for managing dynamic trust, assures trust state of a certificate, and provides a better trust experience for end-users.

The security of web communication via the SSL/TLS protocols relies on safe distributions of public keys associated with web domains in the form of X.509 certificates. Certificate authorities (CAs) are trusted third parties that issue these certificates. However, the CA ecosystem is fragile and prone to compromises. Starting with Google's Certificate Transparency project, a number of research works have recently looked at adding transparency for better CA accountability, effectively through public logs of all certificates issued by certification authorities, to augment the current X.509 certificate validation process into SSL/TLS. In this paper, leveraging recent progress in blockchain technology, we propose a novel system, called CTB, that makes it impossible for a CA to issue a certificate for a domain without obtaining consent from the domain owner. We further make progress to equip CTB with certificate revocation mechanism. We implement CTB using IBM's Hyperledger Fabric blockchain platform. CTB's smart contract, written in Go, is provided for complete reference.

Infrastructure-as-a-Service (IaaS), more generally the "cloud," changed the landscape of system operations on the Internet. Clouds' elasticity allow operators to rapidly allocate and use resources as needed, from virtual machines, to storage, to IP addresses, which is what made clouds popular. We show that the dynamic component paired with developments in trust-based ecosystems (e.g., TLS certificates) creates so far unknown attacks. We demonstrate that it is practical to allocate IP addresses to which stale DNS records point. Considering the ubiquity of domain validation in trust ecosystems, like TLS, an attacker can then obtain a valid and trusted certificate. The attacker can then impersonate the service, exploit residual trust for phishing, or might even distribute malicious code. Even worse, an aggressive attacker could succeed in less than 70 seconds, well below common time-to-live (TTL) for DNS. In turn, she could exploit normal service migrations to obtain a valid certificate, and, worse, she might not be bound by DNS records being (temporarily) stale. We introduce a new authentication method for trust-based domain validation, like IETF's automated certificate management environment (ACME), that mitigates staleness issues without incurring additional certificate requester effort by incorporating the existing trust of a name into the validation process. Based on previously published work [1]. [1] Kevin Borgolte, Tobias Fiebig, Shuang Hao, Christopher Kruegel, Giovanni Vigna. February 2018. Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificates. In Proceedings of the 25th Network and Distributed Systems Security Symposium (NDSS '18). Internet Society (ISOC). DOI: 10.14722/ndss.2018.23327. URL: https://doi.org/10.14722/nd

Currently, no major browser fully checks for TLS/SSL certificate revocations. This is largely due to the fact that the deployed mechanisms for disseminating revocations (CRLs, OCSP, OCSP Stapling, CRLSet, and OneCRL) are each either incomplete, insecure, inefficient, slow to update, not private, or some combination thereof. In this paper, we present CRLite, an efficient and easily-deployable system for proactively pushing all TLS certificate revocations to browsers. CRLite servers aggregate revocation information for all known, valid TLS certificates on the web, and store them in a space-efficient filter cascade data structure. Browsers periodically download and use this data to check for revocations of observed certificates in real-time. CRLite does not require any additional trust beyond the existing PKI, and it allows clients to adopt a fail-closed security posture even in the face of network errors or attacks that make revocation information temporarily unavailable. We present a prototype of name that processes TLS certificates gathered by Rapid7, the University of Michigan, and Google's Certificate Transparency on the server-side, with a Firefox extension on the client-side. Comparing CRLite to an idealized browser that performs correct CRL/OCSP checking, we show that CRLite reduces latency and eliminates privacy concerns. Moreover, CRLite has low bandwidth costs: it can represent all certificates with an initial download of 10 MB (less than 1 byte per revocation) followed by daily updates of 580 KB on average. Taken together, our results demonstrate that complete TLS/SSL revocation checking is within reach for all clients.