Disrupting Blockchain Security: Can a Decentralized Certificate Authority Improve Trust in Cryptocurrency?
The unregulated cryptocurrency market is a thieves’ paradise: last week, exit scammers at the Vietnam-based “Modern Tech” made off with $660 million, a small chunk of the potential billions of dollars already stolen this year. The most widespread form of crypto hack is phishing attacks: the “wallet address” is a cryptographic hash that is unreadable to humans, and it is impossible to determine from a wallet address alone that you are sending currency to the person you intended. Hackers have taken advantage of this basic systemic flaw to convince naive consumers to send them currency through various, clever social engineering tricks.
The current system is unsustainable, and public trust in ICOs is at risk. According to a recent poll, an estimated two-thirds of Americans are not sure whether ICOs are illegal, and 21 percent believe that investing in ICOs is against the law. China, once a rapidly growing ICO market, issued a blanket ban on all ICOs last year. Earlier this year, Google, Facebook, and Twitter all banned crypto-related advertisements in an effort to halt the exploding number of phishing campaigns on their platforms. As an industry we must urgently develop methods of self-regulation to substantially improve the safety and security of blockchain transactions.
Trustroot is developing tools for protecting consumers against phishing attacks. The first step is building a mechanism for establishing trust between consumers and businesses: how can a business communicate to its users that they are who they claim to be, and not a malicious actor? Blockchain companies can verify their business by, for example, submitting proof-of-identity documents (such as legal articles of incorporation) and a signing a wallet “challenge” to prove control over a wallet address. Once a business has been thoroughly vetted, users of the Trustroot Chrome browser extension will see a green checkmark next to the business’ wallet address wherever it appears on the web — conversely, wallet addresses for an unverified business will appear with a red “X” to communicate to users that this entity has not yet been vetted. (The beta Chrome extension currently supports Ethereum wallet addresses only).
Trustroot issues a certificate to a vetted business indicating to users that a wallet address belongs to that business. In the short-term, we are implementing the model of a conventional “certificate authority” because of the urgent need for basic identity verification to improve the safety of blockchain transactions. We want entrepreneurs to set up ICOs with more confidence their investors won’t be scammed — and we want ordinary consumers to transact in cryptocurrency with more confidence it won’t be spirited away by hackers. However, the conventional certificate authority is a flawed model: it requires placing trust in a single entity to accurately and efficiently verify somebody’s identity. Thorough identity verification is a resource-intensive process; it is costly for a single organization to perform the necessary tasks to confirm the existence of a business and rigorously enforce protocols for preventing attacks. Our goal is to use the unique properties of blockchains to build a decentralized certificate authority that eliminates the need for a single “trusted third party.”
A useful analogy for understanding the weaknesses of a centralized certificate authority is the “extended validation” SSL certificate issued for web servers. An SSL certificate is a public key certificate signed by a third party authority that confirms a server belongs to the hostname you intended to connect to, and not an impostor like a man-in-the-middle attacker. An “ordinary” SSL certificate is totally ineffective at preventing phishing attacks, since companies like Let’s Encrypt issue free certificates for any website to encrypt its traffic. Just because data sent to and from the site is encrypted doesn’t mean the entity you are transmitting data to is who they claim to be, and hackers regularly abuse the “trust” signalled by the green padlock in the address bar (this is a common tactic utilized in crypto phishing attacks).
As a solution, in 2007, the Certificate Authority Browser Forum helped develop a high-security certificate, which requires verifying the identity and legal registration of the entity requesting the certificate — in theory, a business must prove that it actually exists, and that it is represented by an actual person. Although this “extended validation” slightly improves the effectiveness of the SSL certificate, it still suffers from the same fundamental vulnerabilities. It isn’t enough to prove that a company or legal entity merely “exists,” because a committed actor can register a fake company for the sole purpose of obtaining EV SSL certs for phishing attacks. In September 2017, a security researcher registered a company called “Identity Verified” under a legitimate name and address (though a malicious actor could easily use a stolen ID obtained on the “dark web”). He then obtained an EV SSL cert through Symantec, one of the largest certificate authorities. Some modern browser interfaces actually remove the URLs of sites with an EV SSL cert, producing extremely convincing attack sites:
In December 2017, security researcher Ian Carroll took things a step further by exploiting another vulnerability in the EV SSL cert process: colliding entity names. Carroll created a dummy site masquerading as Stripe, Inc, the online payment processing service. The real Stripe, Inc is registered as a corporation in the state of Delaware. To obtain an EV SSL cert for his fake site, Carroll registered a corporation under the same name in the state of Kentucky. Because of the limited information provided by modern browsers, it’s unlikely any user would detect the difference:
Although the EV SSL certificate process was designed to create a significant “paper trail” to deter would-be attackers, the system is easy to circumvent in practice. To receive a certificate, a corporation must prove it is registered with and approved by an official registration agency; Symantec, for example, often uses third-party databases like the business analytics firm Dun & Bradstreet to confirm the existence and registration of a corporation. A key finding of Ian Carroll’s study was the lack of individual identity verification required by the certificate authority — identity verification was outsourced to Dun & Bradstreet, which asked some “trivial” questions easily answered using a stolen ID.
Carroll found that CA/Browser Forum’s Baseline Requirements for issuing certificates are not consistently enforced. Although Dun & Bradstreet explicitly states it will reject registration applications using a third-party address, the firm accepted Carroll’s application using a third-party address. An older version of the Baseline Requirements calls for flagging “High Risk Certificate Requests,” for example applications involving “names at higher risk for phishing,” or “names contained in previously rejected certificates or revoked Certificates,” and so on — but these criteria are clearly not being applied.
Safari and Firefox trust more than sixty different certificate authorities, and Microsoft trusts more than one hundred: but some of these authorities have delegated their power to numerous other organizations, which are not audited by the browser companies. According to the Electronic Frontier Foundation’s SSL Observatory, there are more than 600 certificate authorities that are automatically “trusted” by browsers through delegation. Any one of these groups can be compromised by a malicious attacker, and as the EFF’s color map of certificate authorities warns: “HTTPS is only as strong as the practices of the least trustworthy/competent CA.”
The shortcomings of SSL certificates are based on two interconnected problems: the lack of rigorous protocol enforcement, and the existence of a single point of failure, the individual authority deputized to issue certificates. Protocol enforcement is a function of costs: it requires a lot of resources to implement these protocols because different steps require different types of authentication mechanisms, and it is cheaper to delegate these tasks to firms that have specialized expertise. In many industries, corporations performing audits will outsource different steps of the verification process; for example, a health insurance company might subcontract the task of verifying “dependents” on health care plans to a firm that specializes in authenticating birth and marriage certificates. One of the main barriers to rigorous protocol enforcement is the limited resources available to any individual certificate authority to efficiently and accurately verify an entity.
Trustroot is developing a system that seeks to address these problems by leveraging the unique characteristics of blockchains: a decentralized certificate authority. The individual certificate authorities already delegate different steps of the verification process to outside firms. Instead of relying on a single CA, which in turn subcontracts its responsibilities to firms it selects based on its sole discretion, we can break up the verification process into a series of tasks (e.g. authenticating legal articles of incorporation, authenticating the registered agent acting on behalf of the company, performing a challenge method to verify the company’s control of a crypto wallet, checking for colliding entity names or other “high risk” indicators, and so on). These tasks can then be distributed to “workers” somewhat like Amazon Mechanical Turk: a large number of actors perform the verification tasks, and the system picks the “correct” answer based on consensus.
Workers are compensated with tokens for performing verification tasks; the same tokens are purchased by businesses to pay the costs of certification. This system ensures consistent protocol enforcement — it’s no longer possible to ignore a protocol, because the system issues a certificate only if it reaches a certain threshold of agreement between sets of workers performing the same verification tasks. At each step of the verification process, a consensus algorithm determines whether the certificate applicant “passes” according to results reported by the network of workers. A “proof of stake” model would ensure that workers do not flood the system with garbage information, by forcing them to stake their holdings on getting the correct answer to a verification procedure.
A common analogy is applied to describe the advantage of decentralized systems: “What’s less likely to happen: one single computer failing, or five out of ten computers all failing at the same time?” A decentralized certificate authority inherits the unique fault-tolerant properties of blockchains; but if protocols are poorly designed, it doesn’t matter if they are implemented consistently and in good faith. In a blog post on “The Meaning of Decentralization,” Ethereum founder Vitalik Buterin offered an important counter-example: “Four jet engines are less likely to fail than one jet engine, but what if all four engines were made in the same factory, and a fault was introduced in all four by the same rogue employee?” As a community, we must design robust and adaptive verification procedures: fault-tolerant decentralization requires multiple competing implementations of protocols and a democratic process for developing and refining them.
Receiving a certificate from the decentralized certificate authority only indicates that a corporation has met the minimum threshold requirements for verifying its identity — a certificate still does not guarantee that a corporation is trustworthy. Thus, the second major aspect of the Trustroot platform is a reputation management system, a “Yelp”-like model for users to issue reviews of businesses after completing a transaction. With robust identity verification procedures in place, the blockchain overcomes many of Yelp’s conventional challenges with fake reviews: with a chain explorer it is easy to verify whether an individual writing a review actually transacted with a business. Anonymous reviews (where there is no transaction history) can be automatically ‘flagged’ and given a lower priority by the system.
There is no such thing as “perfect” security — dedicated adversaries will always seek new methods of circumventing the system. The best we can do is minimize vulnerabilities and create robust mechanisms for anticipating and defending against attacks, drawing from a concerted community effort. We invite your feedback as we continue developing our platform! You can download the beta Trustroot Chrome extension on the Chrome Web Store, and register your business at our website.
