1 Introductory Remarks
Recently, a number of projects (both from academia and industry) have examined decentralized public key infrastructures (PKI) based on blockchain technology. These projects vary in scope from full-fledged domain name systems accompanied by a PKI to simpler transparency systems that augment the current HTTPS PKI. In our paper, we start by articulating, in a way we have not seen before, why our approach is more than a complementary composition of technologies, but actually a new and useful paradigm for thinking about who is actually authoritative over PKI information in the web certificate model. We then consider what smart contracts could add to the web certificate model, if we move beyond using a blockchain as passive, immutable (subject to consensus) store of data -- as is the approach taken by projects like Blockstack. To illustrate the potential, we develop and experiment with an Ethereum-based web certificate model we call Ghazal*, discuss different design decisions, and analyze deployment costs.
2 Methodology
Our approach is slightly different from other blockchain-approaches to identity (or specically PKI). In the current web certificate model, certificate authorities are meant to be authorities: that is, they are authoritative over the namespace they bind keys to. The reality is that the web still runs largely on domain validated certificates and for domain validation, CAs are not any more or less authoritative over who owns what domain than you or I. They instead rely on indirection. For example, a certificate authority might validate a request by Alice for a certificate for alice.com by sending an email to
admin@alice.com';
// --> with a secret nonce that Alice must type into a webform. This involves 2 levels of indirection: (1) CAs appeal to DNS to establish the MX record of the domain (i.e., the subscriber's mail server's IP address); (2) CAs appeal to SMTP to establish a communication channel to the subscriber. For each level of indirection, there are a set of vulnerabilities which might allow a malicious party to break the verication process and obtain a fraudulent certificate for a domain they do not own. Blockchains are actually a new paradigm for PKI; they collapse the indirection for domain validation. If a PKI were added to a blockchain, who would be authoritative over the namespace of domain names? When domain names themselves are issued through the blockchain (e.g., Namecoin), then the blockchain is actually the authoritative entity. Arguably, this indirection can be collapsed in the traditional web certificate model as well. There DNS (in conjunction with ICANN) is authoritative over the namespace and if ICANN/DNS held key bindings, there would be no indirection or CAs needed.
2.1 The Ghazal* System
Our proposed scheme is entitled Ghazal*, a smart contract-based naming and PKI uni-authoritative system. It enables entities to fully manage and maintain control of their domain names without relying on trusted third parties. In Ghazal*, a user can register an unclaimed domain name as a globally readable identier on the Ethereum blockchain. She is then able to transfer the ownership of her domain name by auctioning it off or changing the Ethereum address of the owner. The domain owner can also assign arbitrary data, such as TLS certificates to her domain. These values are globally readable, non equivocating, and not vulnerable to the indirection attacks . The penalty paid for a uni-authoritative approach is that Ghazal* has to carve out its own namespace that is not already in use (e.g., names ending in .ghazal like Namecoin's .bit or Blockstack's .id). OS and browsers would have to be modified before any system like this can be used. Anyone can claim a domain on a first-come, first-serve basis. Because it is decentralized, names cannot be re-assigned without the cooperation of the owner (whereas an ICANN address like davidduchovny.com can be re-assigned through administrative mediation). The design of Ghazal* consists of two essential elements. First, the smart contract that resides on the Ethereum blockchain and serves as an interface between entities and the underlying blockchain. The second primary component of the system are the clients, including people or organizations that interact with Ghazal* smart contract in order to manage their domain names.
3 Results
Ghazal* smart contract is implemented in ~370 lines of Solidity language and tested on the Ethereum test network. We use the Solidity compiler to evaluate the rough cost for publishing the Ghazal* smart contract on the Ethereum blockchain as well as the cost for the various operations to be executed on the Ethereum virtual machine. As of January 2018, 1 gas = $21\times10^{-9}$ ether, and 1 ether = \$882.92. The estimated costs for Ghazal* smart contract deployment and function invocation in both gas and USD have been presented in our paper. According to Ghazal* cost evaluation, the most considerable cost is the one-time cost paid to deploy the system on the Ethereum. There are then relatively small costs associated with executing the functions, i.e., users could easily register a domain by paying \$3.15 or they could bind a key to the domain they own for a cost of \$1.43, which is relatively cheap when compared with the real world costs associated with these operations.
4 Concluding Remarks
We hope that uni-authoritative systems with programmability continue to be explored in the literature. There are many open problems to work on. First and foremost is understanding the scalability issues and how to minimize the amount of data a client browser needs to fetch for each domain lookup. Blockstack has done an excellent job on this issue for non-programmable contracts. Future work could also look at the layer above the smart contract: building web tools with user interfaces to enable interaction with the underlying functions. Finally, while auctions are one illustrative example of why programmability might be added to a PKI, we are sure there are many others. The modular design of Ghazal* using object-oriented programming should allow easy additions to our base contract, which we will provide as open source. Indeed, the auction itself in Ghazal* was added via inheritance and one function override (to enforce that ownership transfers, part of the parent class, could not be called during a live auction).
Ghazal* is a joint work with Dr. Jeremy Clark. This work is published and presented in the peer-reviewed smart contract workshop co-located with the Financial Cryptography and Data Security conference 2018.
Ghazal* paper's link: https://users.encs.concordia.ca/~seye_moo/documents/Ghazal_paper.pdf
Ghazal* source code: https://github.com/mahsamoosavi/Ghazal