Ethereum 2.0 Security Considerations by Adrian Manning & Paul Hauner (Devcon5)

there we go the slides are not so performant but they are safe so I wanted to give an overview of a theorem to information security professionals so what I want to do is sort of show you where we're looking in the protocol and the implementations and I'm hoping that people will be inspired to come along and perhaps fill in the gaps if you can see am I missing something or it's just with the things that we're working on now and work with the other teams too so I'm gonna be talking about validator safety I'm going to be talking about the phase zero software components how we're viewing it as I said a set of software bits so I'm going to be talking so phase zero it means Casper proof of steak without shards or execution and Adrienne's gonna be talking about value to privacy on the network and the differential fuzzing work that's been going on in f2 so I want to talk about validators as you know they are replacing the miners as the block producers so taking them offline will affect the liveness of the network and stop new blocks which is very bad so I want to talk about the two failure modes of validators so we have these two different modes this is offline validates and equivocating validators so an offline validator is a validator that's either just simply not connected to the Internet of the network or they're on a different minority chain so from the view of the the majority canonical chain whether or not they're just completely offline or whether they're on a different chain it's basically the same to us so these validators they stand to lose in rewards what they would have what they stand to lose in penalties what they would have gained in rewards so they're going to start sort of leaking out at five percent five to ten percent per year this is in the case where there's only just a handful of validators if there's enough validators to prevent finality the system swaps into this mode where it starts to quickly eject validators but this is just so like general individual case our losses so then the other hand we have equivocating validator so these are validators that have produced conflicting messages so the easiest one is you know two blocks are the same height that are different it's a double vote they violated the protocol they're going to lose a lot of state quickly they can get slashed and they're gonna get it back ejected from the validator set so these two modes have two interesting properties the first is that taking evaluator offline is generally an unprivileged attack so if you know a bug that causes a node expend its resources and doing an auto service or or perhaps crash then you can generally do this by just connecting to it on the on the internet and then sending in a package and watching packet and watching it go down whilst on the other hand making it validator equivocate should if the software stack is good require elevated privileges on the host machine so it requires someone to have access to the machine which is running the software of the validator the reason being is that if a validator can keep a history of its previously signed messages it can check these messages and detect if there's a clean and equivocation before it signs a new one so if you imagine the equivocation detection and the signing is just like one black box there should be no message that you do or don't send to it that can cause it to equivocate without it being aware of it beforehand so now I want to move on to the software components this is how the researchers and implementers have been thinking about this system into two distinct components one is the beacon node the other is the validator client so the validator client I'm sorry that the beacon node is what we know is guest this is the big piece of software connects to the p2p network it gets peers imports blog stub state transitions verify signatures but importantly it doesn't sign messages that is the job of the validator client so the validator client it connects to the beacon node and uses it as a source of truth so he doesn't need to connect to the internet directly it connects via the beacon node and then it requests blocks its duties from the from the beacon node signs them and then returns them so this is what we have this relationship where a bad beacon no can cause a validator client to be offline by either sending it nothing or sending it garbage but it shouldn't be able to if there's like a sovereign well maintained validator client the beacon node should not be able to make it be slashed so moving on this is a bit of a networking overview of the two components here here I have these two binaries here that are perhaps in the wrong Linux folders but we'll ignore that they don't necessarily have to be two distinct binary they could be the same thing but this pattern is what we're seeing from the majority of clients and ours included I'll sort of show you why on the next slide but in the terms of networks we have the internet over here which is the untrue zone so this is where we have anybody internet we're connecting to peers via discovery v5 using UDP and then we're talking to those nodes using a lid p2p generally over TCP this is where people can start to you know do denial of service attacks and this is where we need to be cautious of this where on the other hand we have a private network over here so this is a LAN or a VPN something we trust and this is where the validator client connects to the beacon node via an API I have said TCP here but it could be anything so the reason that we have this private network over here is to isolate the validator client from the Internet and reduces the tax service and the people that can get added and I just have been mentioned here so the two databases here there's the beacon node has this is like the big like kind of gets style level to be a rocks DB database full of the chain and the validator client will keep its own database where it maintains its history of messages enough so it can't get slashed and perhaps some private keys either on disk or on a trestle so this is what I was mentioning before about the reason that we've separated the validator client out it's because it can talk to multiple beacon nodes so we may have the case typical pattern would be valid a client connects to one of them uses it as the source of truth of the chain and perhaps it'll when it produces a blocker attestation it may send it to a few of them just to ensure that the that the block gets propagated out to the network and the validator client can also maintain a sense of quality of service of its beacon node so if the beacon node is not responding or it's not it's perhaps referencing some other node to see whether it's blocks are appearing in the chain if it decides the quality of service is not good it can just hop over to another vacant node and because it's maintained a SATA base and sign messages it may be offline during that hop if they're on different chains but it shouldn't be able to be slashed so now as my last slide I just want to go through this is the inside of a beacon node to the big binary and this is kind of like a very simple overview from a security only perspective of what's going on so this is where messages may come in here on the left from the internet and end up in our database or perhaps we're doing a response pulling something from the database and sending it back to the Internet so the first thing that we see from the Internet is an working stack that slip p2p so we're being cautious here of eclipsed attacks we'll be you know surround the validator and give it a minority view of the network alternatively we have to be careful here with but we have to be careful here of validator privacy adren we'll talk about this and we're also wary of resource exhaustion here if we can make the p2p do too much work and slow us down we have marshalling where we're encoding and decoding bytes from the network so we have a new encoding and decoding scheme that's simple serialized SS said it is quite simple and straightforward but it is new and it uses pointers they're called offsets so here we need to be quite careful of our seg faults and all the interesting things that come with encoding formats and perhaps on the higher level here we have a consensus message that we may intend to import to our database on the lower level here we're validating requests that we may give back to response to someone so the consensus message validation is is a very complex piece of software so this is the implementation of the earth 2.0 specs repository so this the earth 2.0 specs has written optimized for readability but not for speed of execution so one of the really important things that client developers must do is produce optimized versions of this specification so we need to be careful that these optimizations don't cause consensus Forks you know given the same blocking state we produce the same post state so we're paying particular attention here through fuzzing which agen we'll talk about we're also very cautious of resource exhaustion here perhaps someone sends a block that's valid but takes a long time to put to process we want to we want to really avoid this something else we want to be particularly careful of is blocks where it takes us a long time to determine whether or not it came from a valid producer so sometimes we have to do work to figure out who should have produced the block so we need to be particularly careful here because if people can make us do work to figure out who should have sent it that means anyone can send it to us so these are attacks that are open to anyone not just people that are inside the validator said so this is something we've been actively working on lately there's a lot of arithmetic in here addition subtraction division that can you know divide by zero or we can have underflow as overflows we're also doing a lot of access to arrays in here where we're rewarding people so this is where we need to be very careful of seg faults too and then finally here we have the request validation so this is where we've serum su has a new networking protocol so during the design we're being quite cautious to make sure that we don't allow for requests that may take an unreasonable amount of time in order to respond to them or process them so this is the end of my slides and we're going to be hearing from Adrienne about validator privacy and differential fuzzing yeah so for the rest of this talk I just wanted to give a very brief overview of two specific examples of some etherium some security considerations in etherium - so specifically validated privacy and differential fuzzing so for validated privacy what our valide is we need to know what these guys are first which I'm sure you all know but anyway validators are aetherium two entities that drive consensus via staking a theorem and performing specific tasks in particular they need to vote on shards and beacon blocks and at the network layer they need to produce blocks and they need to produce attestation x' so that means if you want to be a validator you need to have a beacon node that's connected to the network that actively produces blocks produces outa stations so I want to try and kind of give you a high-level overview of what the actual issue we have with validator privacy in aetherium - we're using a protocol to publish and propagate blocks and annotations on the network called gossip sub there's protocol labs I think in about an hour or giving a deep dive into this particular protocol but right now I just want to give a like a very high-level overview of roughly how it works and and why there's an issue or a potential issue or security consideration inside of that so this is a simple peer-to-peer network that's what I'm trying to what I'm trying to show here in this diagram each of the circles are beacon nodes the direct lines or the solid lines between those the direct connections physical connections IP IP TCP connections if you want between the nodes and you can consider this as a very rough aetherium to peer-to-peer network so of all the nodes in the network there's a subset of nodes which are validator nodes what I mean by a validator node is a beacon node that has a validator client attached to it and they're the ones that are producing blocks are attestations when we publish a block or an attestation on the network let's consider this validator node in the middle when we want when he wants to he or she wants to produce a block on the network it uses gossip sub the way that this works so publisher block is you select a subset of your connected peers and you send them the block intern they do the same thing in turn they do the same thing and the block or attestation gets propagated across the network such that the entire network receives the block okay so what's the issue with this the issue is that the first people you initially connect to what happens if one of them is malicious they have a direct connection to you so they know what your IP address is if you're a validator client on the network in practice and malicious actor was actually going to release or deploy a whole range of these nodes and through timing analysis they can actually work out who were the validators specifically their IP addresses on the network so assuming that you can perform this attack you can essentially collect the IP addresses or the physical addresses of all the validators on the network so why is this an issue so it's an issue for a number of reasons the first one is that you if you know a specific valid a as IP address you can target that computer and you can das it you can perform an eclipse attack for example which segregates it from the network a validator that's segregated from the network can't perform its task that's required to do and therefore it's valid it there that will lose their stake so what that means in practice if someone comes along and says that you look fat in a pair of jeans you go right oh I'm gonna find your IP address you segregate them from the network and they lose their stake as punishment a more a more severe attack and sophisticated hackers if you if you know all the Valladares IP addresses on the network you perform a large-scale attack on a majority of those Valadez and you kick a majority of holidays off the network so that they cannot perform their tasks if you do that you can prevent or delay chain finalization because the majority of holidays aren't finalizing or agreeing on blocks you can amplify validate a loss because if a large number of valid a's are disconnected from the network at the same time it amplifies the amount of stake that and you can increase your own rewards by removing competing valide so it gives you some incentive to perform these attacks so this is an active research topic in aetherium too at the moment so we don't have a specific solution is what we're actually going to use but there have been some proposed solutions so some ideas are that we can run a set of backup dos Harden nodes so what that means is that if you are running a validator client with a beaker node in you publishing blocks and access stations and you find that they're not being received on the network you can point your validator client to one of these hardened backup dos hardened beacon nodes or beacons yeah beacon nodes which will then propagate it for you another solution is that for all validator nodes you could probably put them behind tor ITP or mixed net switch network layer kind of infrastructures which which master IP address but there's there's some latency issues with this there has been some analysis about how bad this is handle is an attestation aggregation strategy which has been proposed by Pegasus firm consensus they're also dealing with this problem so if you're interested in this kind of thing I suggest having a look through some of their research papers I'll have some references afterwards another interesting idea is adding dandelion inside gossip sub so again gossip sub is our message propagation system dandelion is an anonymization framework for anonymizing Bitcoin transactions on the Bitcoin network and I just want to give a rough overview of how that might work you know in our gossip sub network or what has currently been suggested so with dandelion there's an initial phase so instead of us when we want to produce a block or publisher block across the network we don't use gossip sub immediately we route it through a few peers first and then those peers on our behalf will propagate it via gossip sub this is a stochastic process so there's a random number of nodes that it gets routed through so as a very rough overview of how this works let's consider the same a validator know that wants to produce this that publish the same block if we have dandelion in it the first and anonymizing phases we route it through two adjacent peers we choose them each of those peers then for example flip a coin and they flip a coin as to whether they are going to propagate it by a Gauss so on behalf on or forwarded on to another block so the first P let's say the one at the bottom he's flipped a coin and he is going to propagate it across the network the top one flips the coin and finds out I'm not actually going to propagate it I'm going to pass the block on to somebody else to then propagated via gossip sub so those two peers then do the same coin flip and they find out that they're also going to propagate by gossip sub so we now have three nodes that are going to propagate via gossip sub which just does the exact same process as what we did earlier propagates across the network so in this example or in this scenario we find that the blue peers are the ones that are the first ones that have received it via the gossip side messages and to from their perspective it looks like that these three nodes that decided it are the source nodes for each of the gray nodes that receive the message they're unsure about which the source was because the packet they received could have either been the source or just another peer that has just flipped the coin in is propagated on behalf of somebody else so this is the rough idea of anonymizing the validator client source inside of gossip sub again this is an active research topic that we haven't decided on what we're doing there's I encourage anybody that's interested in in this kind of a problem to look at the online discussions that we're having at the moment or to contact us afterwards or just have a chat because there's some interesting problems that we should we should address here so here are some references to have a look at further details as I only have time to just very hand wavy kind of go over this so secondly I want to talk about differential fuzzing differential fuzzing is a project that Sigma Prime has recently adopted in an attempt to security harden all aetherium clients perform a net so let me explain what differential fuzzing is by firstly explaining what fuzzing is fuzzing is a security analysis tool used to find abnormal behavior in software so if we consider an arbitrary program for example a rust as I said crate you can think of this as just an arbitrary function that has a set of inputs and a set of outputs fuzzer generates arbitrary data puts it in as inputs and verifies that the outputs are what you expect or if you have something explode then you know something's wrong with your code if you actually have the source code you can do something called guided fuzzing which allows the fuzzer to instrument the source code and mutate the input functions such that it maximizes the code execution paths of your function so you can maximally check that your code does what it expects and you try and find these bugs so how does this relate to a theorem to in aetherium to there's a whole range of clients over a variety of different programming languages each of the clients have implemented the consensus logic their own way and if they're so there is a chance that any of these clients given a set of inputs could produce an output that is different to another client and this is bad because if we run this on a network and a malicious actor knew what that input was and it could segregate one of the clients from the rest all users that are using that client on the network could in principle have a consensus fork across the network which is something we really really do not want so the idea is we want to before we hit main that is to ensure that all of these clients that are that have implemented the etherium to consensus logic implement it in such a way that all of the inputs are pretty much every input we can possibly give it produce the same output amongst all the clients so we don't get these forking amongst the clients so specifically the each of the clients implement a whole range of functions on the network level and consensus level in everywhere but there's the main core consensus things we really want to test the state-transition functions there's a whole heap of functions involved in this but you can kind of summarize these into three main functions the state processing block processing and epoch processing so these are the main ones we want to target to ensure that all the clients conform to so the way this is done in a single slide very high-level overview is we have a piece of software which we call a differential fuzzer it has plugins that essentially we allows us to plug in each of the clients more specifically their state transition functions and the buzzer itself will similar to an ordinary files they generate a whole heap of random inputs designed for the state transition functions send them individually to each of the clients get a response and make sure all the clients agree on the response if there's a difference then we know that there's a difference between the implementations in the clients and we were going to check this is something that we are currently actively developing we still need to onboard a number of clients and again anyone that's interested I encourage you to come and have a chat with us after so I only had enough time to really just very highly go over some security considerations that we have to give you a rough idea of some of the things that are going on but this is the end of our talk so if you're interested in any of these topics I encourage you to come and contact Paul or I or anyone else around thank you [Applause]