Incentives in Security Protocols

The 2018 edition of the International Security Protocols Workshop took place last week. The theme this year was “fail-safe and fail-deadly concepts in protocol design”.

One common theme at this year’s workshop is that of threat models and incentives, which is covered by the majority of accepted papers. One of these is our (Sarah Azouvi, Alexander Hicks and Steven Murdoch) submission – Incentives in Security Protocols. The aim of the paper is to discuss how incentives can be considered and incorporated in the security of systems. In line with the given theme, the focus is on fail-safe and fail-deadly cases which we look at for the cases of the EMV protocol, consensus in cryptocurrencies, and non-economic systems such as Tor. This post will summarise the main ideas laid out in the paper.

Fail safe, fail deadly and people

Systems can fail, which requires some thought by system designers to account for these failures. From this setting comes the idea behind fail safe protocols which are such that even if the protocol fails, the failure can be dealt with or the protocol can be aborted to limit damage. The idea of a fail deadly setting is an extension of this where failure is defended against through deterrence, as in the case of nuclear deterrence (sometimes a realistic case).

Human input often plays a role in the use of the system, particularly when decisions are required as in fail safe and fail deadly instances. These decisions are then made according to incentives which can aligned to make the system robust to failure. For a fail deadly alignment, this means that a person in position to prevent system failure will be harmed by the failure. In the fail safe case, the innocent parties should be protected from the consequences of system failure. The two concepts are really two sides of the same coin that assigns liability.

It is often said that people are the weakest link in security, but that is an easy excuse for broken protocols. If security incentives are aligned properly, then humans are the strongest link.

The EMV protocol, adding incentives after the fact

As a first example, we consider the case of the EMV protocol, which is used for the majority of smart card payments worldwide, as well as smartphone and card-based contactless payment. Over the years, many vulnerabilities have been identified and removed. Fraud still exists however, due not to unexpected protocol vulnerabilities but to decisions made by banks (e.g., omitting the ability for cards to produce digital signatures), merchants (e.g., omitting PIN verification) and payment networks not sending transactions details back to banks. These are intentional choices, aiming to saves costs and cut transaction times but make fraud harder to detect.

Continue reading Incentives in Security Protocols

Smart Contracts and Bribes

We propose smart contracts that allows a wealthy adversary to rent existing hashing power and attack Nakamoto-style consensus protocols. Our bribery smart contracts highlight:

  • The use of Ethereum’s uncle block reward to directly subsidise a bribery attack,
  • The first history-revision attack requiring no trust between the briber and bribed miners.
  • The first realisation of a Goldfinger attack, using a contract that rewards miners in one cryptocurrency (e.g. Ethereum) for reducing the utility of another cryptocurrency (e.g. Bitcoin).

This post provides an overview of the full paper (by Patrick McCorry, Alexander Hicks and Sarah Meiklejohn) which will be presented at the 5th Workshop on Bitcoin and Blockchain Research, held at this year’s Financial Cryptography and Data Security conference.

What is a bribery attack?

Fundamentally, a wealthy adversary (let’s call her Alice) wishes to manipulate the blockchain in some way. For example, by censoring transactions, revising the blockchain’s history or trying to reduce the utility of another blockchain.

But purchasing hardware up front and competing with existing miners is discouragingly expensive, and may require a Boeing or two. Instead, it may be easier and more cost-effective for Alice to temporarily rent hashing power and obtain a majority of the network’s hash rate before performing the attack.

Continue reading Smart Contracts and Bribes

EPFL blockchain summer school

This year EPFL hosted a Blockchain Summer School from the 21st to the 24th of June. UCL was well represented with Sarah Meiklejohn presenting two talks whilst Sarah Azouvi, Patrick McCorry, Mustafa Al-Bassam and Alexander Hicks also attended. This blog post is a joint effort from the four of us, aimed at highlighting the talks presented last week.

Patrick, Sarah, Sarah, Mustafa, Rebekah (UCL alumni) and Alex. Credit: Emin Gün Sirer

The Summer School featured talks on several aspects of blockchain technology ranging from classical distributed computing, security of smart contracts in Ethereum and proving the security of proof of work/stake. Here, we will provide a small summary for each of the talks. Slides can be found by clicking on each talk on the school’s program page.

TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation by Arthur Gervais: Gervais’ talk highlights that a slight modification to TLS can allow a smart contract to verify the authenticity of data received from website.  Essentially, at the end of the TLS session the server signs evidence of the TLS session if requested by the client. This evidence is verified and stored by the smart contract. It is also worth mentioning that the protocol relies on redactable signatures that ensures private data isn’t revealed.

Town Crier: An Authenticated Data Feed for Smart Contracts – Ari Juels: Juel’s talk highlights that trusted execution environments can be leveraged to build authenticated data feeds. This trusted hardware communicates with the website before sending the data to the smart contract.  It is responsible for setting up a HTTPS session and fetching data from a website before sending the data to the smart contract. TownCrier is currently implemented using Intel SGX and is currently released for testing.

It is also worth mentioning that Juels beautifully provided a good definition for a smart contract:

“A smart contract is a trusted third party with public state.”

This is one of the reasons why cryptography and smart contracts are a great combination. The contract can ensure the cryptography is faithfully executed, whereas the cryptography can provide integrity and confidentiality for data used by the contract.

Continue reading EPFL blockchain summer school