Ethereum Blog

How do you know Ethereum is secure?

Introduction

user

Jutta Steiner


LATEST POSTS

Security Alert – [Previous security patch can lead to invalid state root on Go clients with a specific transaction sequence – Fixed. Please update.] 10th September, 2015

Security Alert – [Implementation bug in Go clients causing increase in difficulty – Fixed – Miners check and update Go clients] 03rd September, 2015

dev update

How do you know Ethereum is secure?

Posted on .

As I’m writing this, I’m sitting in the London office and pondering how to give you a good overview about the work we’ve been doing to secure Ethereum’s protocols, clients and p2p-network. As you might remember, I joined the Ethereum team at the end of last year to manage the security audit. As spring has passed and summer arrived and meanwhile several audits finished, it’s now a good time for me to share some results from the inspection of the world computer’s machine room. 😉

This much is clear, as much as the delivery of the clients is an elaborate product development process, it is an exciting yet heavily complex research effort. The latter is the reason why even the best planned development schedule is subject to change as we discover more about our problem domain.

The security audit started at the end of last year with the development of a general strategy for ensuring maximum security for Ethereum. As you know, we have a security driven, rather than a schedule driven development process. With this in mind, we put together a multi-tiered audit approach consisting of:

  • Analyses of the new protocols and algorithms by established blockchain researchers and specialised software security companies
  • End-to-end audit of protocols and implementation by a world-class expert security consultancy (Go followed by C++ and a basic audit for the educational Python client), as well as
  • The bug bounty program.

The analyses of the new protocols and algorithms covered topics like the security of:

  • The gas economics
  • The newly devised ASIC-resistant proof of work puzzle as well as
  • The economic incentivisation of mining nodes.

The “crowd-sourced” audit component started around Christmas along with our bug bounty program. We had set aside an 11-digit satoshi amount to reward people who found bugs in our code. We’ve seen very high quality submissions to our bug bounty program and hunters received corresponding rewards. The bug bounty program is is still running and we need further submissions to use up the allocated budget…

The first major security audit (covering the gas economics and PoW puzzle) by security consultancy Least Authority was started in January and continued until the end of winter. We are very glad that we agreed with most of our external auditors that those audit reports will be publicly available once the audit work and fixing of the findings is completed. So along with this blog post, we are delighted to present the Least Authority audit report and accompanying blog post.  In addition, the report contains helpful recommendations for ÐApp developers to ensure secure design and deployment of contracts. We expect to publish further reports as they become available.

We have also engaged another software security firm at the beginning of the year to provide audit coverage on the Go implementation. Given the increased security that comes with multiple clients and as Gav mentioned in his previous post, we have also decided to give the Python and C++ audit a lightweight security audit starting early July. The C++ code will receive a full audit right after – our goal with this approach is to ensure several available audited clients as early as possible during the release process.

We kicked off this most encompassing audit for the Go client, aka the “end to end audit”, in February with a one-week workshop that would be followed by weeks of regular check-in calls and weekly audit reports. The audit was embedded in a comprehensive process for bug tracking and fixing, managed and thoroughly tracked on Github by Gustav with Christoph and Dimitry coding up the corresponding required tests.

As the name implies, the end-to-end audit was scoped to cover “everything” (from networking to the Ethereum VM to syncing layer to PoW) so that at least one auditor would have cross checked the various core layers of Ethereum. One of the consultants recently summarized the situation pretty succinctly: “To be honest, the testing needs of Ethereum are more complex than anything I’ve looked at before”. As Gav reported in his last blog post, because of the significant changes in the networking and syncing strategy we eventually decided to commission further audit work for Go – which we are about to finish this week. The kick-off for the end-to-end C++ and basic Python audits is taking place now.

The audit work with subsequent bug fixing and regression testing as well as related refactoring and redesign (of networking and syncing layer) make up the majority of work that’s keeping the developers busy right now. Likewise, fixing of findings, redesign and regression testing are the reason for the delay in the delivery. In addition, the Olympic testing phase has taught us a great deal about resiliency under various scenarios, such as slow connections, bad peers, odd behaving peers and outdated peers. The greatest challenge so far has been fighting off and recovering from forks. We learnt a lot from the recovery attempts in terms of required processes when it comes to dealing with these type of scenarios and incidents.

It might not come as a surprise that the various audits represent a significant expenditure – and we think money that could not be better invested.

As we draw closer to release, security and reliability is increasingly uppermost in our minds, particularly given the handful of critical issues found in the Olympic test release. We are very grateful for the enthusiasm and thorough work that all auditors have done so far. Their work helped us sharpen the specification in the Yellow Paper and to weed out ambiguity and fix several subtle issues, and they helped with identifying a number of implementation bugs.

profile

Jutta Steiner

Comments
user

Author Henrik Jonsson

Posted at 10:50 am July 7, 2015.

You guys may already be aware, but your SSL cert expired today (somewhat ironically, given this blog title):

Common Name (CN) *.ethereum.org
Organization (O)
Organizational Unit (OU) Domain Control Validated
Serial Number 76:B6:23:4F:0B:3B:D1:CF:D6:9D:72:92:36:06:C4:DE

Issued By
Common Name (CN) COMODO RSA Domain Validation Secure Server CA
Organization (O) COMODO CA Limited
Organizational Unit (OU)

Validity Period
Issued On 7/6/14
Expires On 7/7/15

Fingerprints
SHA-256 Fingerprint 6A F6 15 47 79 C6 78 EC 2A 37 23 1E 25 23 1E 30 3E B9 20 D3 88 36 C4 F3 13 BA F2 24 A1 C8 EE 41
SHA-1 Fingerprint A4 2D 9C 8F 5F 9A D1 A8 A1 BF 5D 74 90 1A 2F C7 81 A6 45 E7

Reply
user

Author Paul Paschos

Posted at 7:47 pm July 7, 2015.

Dapp devs – take a look at the recommendations surrounding defensive programming when composing smart contracts.

Reply
user

Author Alexey

Posted at 11:43 pm July 9, 2015.

I am reading the audit report, and find it very insightful, totally recommend to everyone! Thanks for sharing, Jutta

Reply
user

Author amir

Posted at 9:59 pm July 11, 2015.

where is the audit report?

Reply
user

Author Hussain Said Mourad

Posted at 9:30 pm June 12, 2016.

Can we have a more clear and synthetic overview? Something users would like to know?

Reply

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

View Comments (7) ...
Navigation