devcon 5 / erc725 the future of on chain interaction
Duration: 00:28:57
Speaker: Fabian Vogelsteller
Type: Breakout
Expertise: intermediate
Event: Devcon
Date: Invalid Date
How do we make dapps as secure as the underlying Ethereum?
Web3.js is a Javascript API for web applications (dapps) to access Ethereum blockchain. However, its security assumption inherited the security assumption of an Ethereum node, which is entirely open to the node's owner. The privacy and security consequences of that assumption are two-fold. First, a web application can learn sensitive information about the user. Second, the web application can feign a representation of blockchain data to be another or even tricking users to signing obfuscate transactions. A website which simply draws a crypto kitty would look no different than another which reads the user’s kitty from Ethereum smart contracts. Much makeshift work has been down for this underdesigned infrastructure. For example, MetaMask resorted to hardcoding CryptoKitty and requesting permission to read the user's address. However, only so much patches could do. Furthermore, such patches weren’t designed with abstraction to accommodate next-generation blockchains with privacy and efficiency improvements. For example, failing to find truth quickly using the low-level interfaces provided by web3.js, many dapp browsers resorted to relying on a centralised token status database. The speaker presents a design which abstracts token interface away from low-level Eth-node interface, remodels the basic web code trust inheritance for practicality and security. It involves high-level API for web applications and a secure, WebAssembly based sandbox running signed code designed to embed in the Web itself.
LavaMoat: MetaMask's approach to secure apps
Cryptocurrency is a juicy target for attackers: just grab the coins and run! As app developers, how can we protect our users? Especially given the new trend of "supplychain attacks" where the attackers get into your own app code! LavaMoat is a set of tools to help keep invaders at bay.
Smart contract interaction out of the coldest of storage
At Coinbase Custody, we provide top of the line security for our client's assets. This security comes at a cost though. Through its very nature, our cold storage process creates friction when broadcasting transactions to the network. For HODLers, this friction is a welcome and blessed thing, as it keeps their funds safe. When our clients want to use their funds to participate in decentralized applications however, we have had to get creative. This talk will focus on the patterns we have developed to facilitate rich and convenient network participation between our clients and the decentralized networks they patronize.
Batched Bonding Curves: Grieving DEX Frontrunners
It's been widely publicized that front-running is rampant across decentralized exchanges. Billy Rennekamp describes the technique developed to stop the parasitic behavior by using batched orders in tandem with bonding curves and how it's being used in a new fundraising app by Aragon Black.
Build a constraint system, prover and verifier using OpenZKP Stark
There are great tools and tutorials for R1CS proof systems (aka Snarks) but not much is known about programming Starks. Starks have a much more complex constraint language, but in return you can achieve a much better performance. In this workshop we will * learn about the mathematical underpinnings of Stark proofs, * use 0x's OpenZKP library to generate and verify proofs, and * implement a Stark constraint system.
(Defense Against) The Dark Arts - Contract Runtime Mutability
Smart contracts are no longer guaranteed to have immutable runtime code, and can be redeployed with new code using a variety of methods involving the CREATE2 and SELFDESTRUCT opcodes. In this presentation, we will investigate how this is done and how to protect against malicious mutable contracts. We will also explore ways these new techniques can be applied in order to enable new use-cases and to improve the user experience.
Fuzzing the Solidity Compiler
Since the Solidity programming language does not have a formal specification, testing the compiler implementation is an important way to obtain assurance about the correctness of code generated by the compiler. Fuzz testing is well-suited for this setting. However, applying fuzzing in the traditional manner (random input generation that is coverage-guided) is inefficient for testing compilers because a significant fraction of randomly generated code is syntactically invalid. If the fuzzer does not generate syntactically correct Solidity programs, the compiler will simply reject it. As a consequence, code optimization and generation subsystems of the compiler will not be tested. The approach adopted by us is to define a grammar for the Solidity programming language and automatically generate inputs based on this grammar. Grammar based fuzzing ensures that generated programs are successfully parsed by the front-end parser. We make use of libProtobuf and libProtobufMutator for defining the grammar and performing grammar-based mutations, and libFuzzer as the underlying fuzzing engine.
Keymanagement: Multisig based Custody as Enabler for Mass Adoption
Key management is a fundamental challenge in the widespread use of blockchain technology. Especially when it comes to managing large tokenized values, a suitable custody service is essential. While many existing custody services are primarily based on technologies such as Shamir's Secret Sharing, it makes sense to use a Smart Contract based Multisig to manage the rules such as access, what signatures are required, time delay, recovery of lost accesses, etc.
Securely storing wallet private keys for application use
Private key management is a complex problem in cryptography. In the last few years, we have seen attacks against cryptocurrency companies that seek to retrieve the private keys of user wallets. Within cryptocurrency, private key management has an additional complexity: the value of stored user funds related to that private key. Truly, key management is a challenge that has plagued secure computing for years.While storing keys is essential, it is equally important to securely use those keys in an application. Without secure use of private keys, applications are vulnerable to attacks to exfiltrate those private keys.In this talk, we will discuss the approach the AirSwap team uses to securely store and use private keys for high value wallets. We will show real world permissions, policies, and code used by our team. We will discuss common attacks against private key management systems and the ways that our implementation thwarts those attacks.This talk is beneficial to any team or company that interacts with the Ethereum blockchain via signed transactions and off-chain custom code. It is essential for any team that wishes to use a private key in their application code securely.
The Gas Siphon Attack: How it Happened and How to Protect Yourself
The Gas Siphon Attack allows anyone to siphon value from many exchanges in the form of gas refunds, a mechanism built directly into the Ethereum protocol. Users can write a simple script that continuously drains unprotected exchange hot wallets of all of their ETH. Until this was responsibly disclosed, many exchanges were affected with varying degrees of severity. How it happened, who was affected, and the technical details behind the attack are discussed during the presentation. The talk dives into the details of the refund mechanism built into the Ethereum network, and how it can be maliciously abused. The presentation explains who is vulnerable and what they can do about it. Finally, the talk covers different ways to protect yourself and your dapp from both known and unknown exploits. Preventative measures are presented that will allow for protection from these types of attacks.