Cryptocurrencies with Security Policies and Two-Factor Authentication
Total Page：16
File Type：pdf, Size：1020Kb
Cryptocurrencies with Security Policies and Two-Factor Authentication Florian Breuer∗ Vipul Goyal Giulio Malavolta∗ KIT NTT Research and CMU MPI-SP Abstract—Blockchain-based cryptocurrencies offer an ap- their decentralized and borderless nature make them pealing alternative to Fiat currencies, due to their decen- appealing substitutes for Fiat currencies, a burning tralized and borderless nature. However the decentralized problem with this approach is the lack of a recovery settings make the authentication process more challenging: mechanism if something goes wrong. What happens if Standard cryptographic methods often rely on the ability of one user’s key is lost or stolen? There is no bank to users to reliably store a (large) secret information. What call and no authority to rely upon to get your funds happens if one user’s key is lost or stolen? Blockchain back. Indeed, the number of such high profile attacks systems lack of fallback mechanisms that allow one to on cryptocurrencies has been rising steadily. Famous recover from such an event, whereas the traditional banking incidents like the Mt. Gox hack [14], the coincheck system has developed and deploys quite effective solutions. hack [2], and the Parity Technology code deletion [3] In this work, we develop new cryptographic techniques saw funds upwards of several hundred million dollars to integrate security policies (developed in the traditional being lost or stolen. The well-known DAO hack [32] banking domain) in the blockchain settings. We propose forced Ethereum to adopt a hard fork which created a system where a smart contract is given the custody of two version of the currency: Ethereum and Ethereum the user’s funds and has the ability to invoke a two-factor classic. To deal with such problems in future, Ethereum authentication (2FA) procedure in case of an exceptional developers have proposed EIP 867. An ethereum improvement protocol (EIP) is the process by which event (e.g., a particularly large transaction or a key recovery code changes get accepted onto the Ethereum platform. request). To enable this, the owner of the account secret- However EIP 867 has proven to be controversial since it shares the answers of some security questions among a will again bifurcate the currency into two versions, the committee of users. When the 2FA mechanism is triggered, very problem it was trying to solve. the committee members can provide the smart contract The problems of attackers stealing money or losing with enough information to check whether an attempt was credentials are of course not unique to blockchain-based successful, and nothing more. cryptocurrencies. The (traditional) banking industry has We then design a protocol that securely and efficiently been dealing with such issues for decades where a number implements such a functionality: The protocol is round- of mitigating approaches have worked pretty effectively. optimal, is robust to the corruption of a subset of committee Examples of common security policies to deal with such members, supports low-entropy secrets, and is concretely attacks include: A waiting period (say 24 hours) for efficient. As a stepping stone towards the design of this transferring money to a new recipient and an overall daily protocol, we introduce a new threshold homomorphic en- outgoing transfer limit. Bypassing these restrictions could cryption scheme for linear predicates from bilinear maps, either require additional verifications (such as two-factor which might be of independent interest. authentication), or may not be allowed at all. Different To substantiate the practicality of our approach, we im- banks could follow different security policies which might plement the above protocol as a smart contract in Ethereum also vary depending on the type of account (business vs and show that it can be used today as an additional safe- personal) and by the state/region and the local laws. This guard for suspicious transactions, at minimal added cost. We motivates the following question: also implement a second scheme where the smart contract Can we take the lessons learnt in the traditional additionally requests a signature from a physical hardware banking domain, and apply them fruitfully to token, whose verification key is registered upfront by the blockchain-based systems, without compromis- owner of the funds. We show how to integrate the widely ing their decentralized nature? used universal two-factor authentication (U2F) tokens in blockchain environments, thus enabling the deployment of 1.1. System Architecture our system with available hardware. We propose a system where each user has the opportu- 1. Introduction nity to delegate the custody of its funds to a smart contract. The security policy (which can be specified by the user Bitcoin and blockchain-based cryptocurrencies itself) is hardwired in the smart contract and it governs its brought us at the brink of a technological revolution: decision. All funds transfer will go through the approval These systems allow us to bypass the need for centralized of such a smart contract, which has the power to accept trusted entities to run currencies on a large-scale. While or reject (or even set on hold) each transaction, depending on the specified policy. In case of an exceptional event, ∗Work done in part while at CMU such as key theft, or as an additional security safeguard in case of particularly large transactions or transactions to then broadcasts a message to all committee members, who new addresses, the smart contract will require additional perform some computation locally and output a partial verification via two-factor authentication (2FA). We stress response tied to the transaction τ. The smart contract that one does not need to authenticate all transactions but then collects sufficiently many responses and publicly only a carefully chosen set, at the discretion of the policy checks whether the authentication was successful. If this specified by the owner of the funds. is the case the smart contract allows τ to go through, In this work we implement the above idea by develop- otherwise it rejects it. In terms of security, we require ing solutions for 2FA mechanisms that can coexist with that the above process does not reveal anything beyond the decentralized nature of blockchain-based currencies. whether the user’s guess was correct or not, even if the To be aligned with the philosophy of decentralized system, attacker corrupts a certain subset of committee members. our solutions are guided by the following design princi- Henceforth, we refer to this procedure as a distributed ples. zero-tester (DZT).1 Distributed Trust. The 2FA must not rely on the ex- We also consider an alternative setup where we lever- istence of a trusted authority. Instead we propose to age a physical two-factor authentication token. As an leverage a hardware token or distribute the trust among example, universal two-factor authentication (U2F) tokens a (reasonably-sized) set of parties, which are asked to in- allow a user to sign any message by querying the token. tervene in case of exceptional event. The members of such With this tool at hand, authentication is done as follows: a committee can be chosen by the users or can be selected The smart contract hardwires the verification key of the through a consensus protocol (e.g., the miners themselves U2F token and, when the 2FA mechanism is invoked, can play this role). Security must be guaranteed even if a sends the user a nonce. The authentication is successful subset of the committee members behaves maliciously. if the user provides a correct signature on the nonce. Reliability and Guaranteed Output Delivery. We re- quire the 2FA mechanism to be resilient against (benign) 1.3. Security Policies disconnections and (malicious) denial of service attacks. That is, even if part of the members of the committee go Our system is completely flexible in the policy that is offline or become corrupted, one should still be able to enforced by the smart contract, which can be specified by complete the authentication procedure (given that the set the owner of the address. A more conservative usage of of online parties is large enough). our system is just as an additional safeguard mechanism: Low Latency. In distributed environments communication Suspicious transactions (e.g., unusually large amounts or is typically expensive, as messages have to be broadcasted transactions to a new address) can trigger the 2FA mech- to all users in the network. For this reason it is of central anism and force the user to provide (human-memorable) importance to minimize the rounds of communication of answers to some security questions or a signature from a 2FA mechanism. a physical token. This gives an additional line of defense Computational Efficiency. General purpose crypto- even against the catastrophic event where an attacker steals graphic solutions are very powerful but are often com- a user signing key. putationally intensive. We aim to build a solution based On the other side of the spectrum, one user may on well-established cryptographic components which is want to set the policy such that some transactions are efficient enough to be integrated in real-life systems. allowed given only the 2FA, i.e., they are not required to be digitally signed. This can be useful in scenarios where 1.2. Two-Factor Authentication Mechanisms a user has lost the signing key for an address and wants to recover the funds: Answering some security questions A popular approach to 2FA in the traditional banking allows him to transfer the coins to a fresh address (with system is that of security questions: When the 2FA is a newly sampled signing key). However this liberal usage triggered, the user is prompted to answer a personal of our system requires careful thoughts. While on the one question and the verification process succeeds if the user’s hand it improves the usability of the currency, on the other answer is correct.