Ladislaus von Daniels - Validating from hardware enclaves

Transcript

hello everyone and I would like to introduce our next speaker it's ladislav he's a longtime member of the East acre community and today he's going to be talking to us about validating from Hardware enclaves take it away L love hey everyone uh thank you very much for coming um my name is l as Nolan said thank you very much uh I'm a member of the East DEA community and uh I'm very humbled to um be able to speak to you today um about validating from Hardware enclaves um please take in mind uh I am everything but a computer security researcher so take everything what I say here with a with the appropriate grain of thought I'm simply reporting back sort of my experiences when tinkering

and testing and using those uh tools we're going to talk about um um today uh and sort of give a high level overview conceptually also uh and it takes about let's say 15 minutes and then I hope we've got some some time for questions um so quick recap to get things started um we're talking about valid data key protection today and um yeah of course to avoid common slashing risks and uh valid data key protection is um is not trivial um so I've brought uh brought up here this this iconic diagram from the fine folks from a tant um basically you know showing the different layers of protections uh for valid data Keys uh not a lot has changed

since since this has been published um so basically we start at the at the nucleus right with sort of the default of protecting Keys um meaning they have to be hot on dis right you generate your key store and then have an uh attached to it pass race and then the further out you go the the security layers if you will then you sort of reach at some point maybe the separation of concerns between a valid dat client and your remote signing software such as web 3 signup by consensus and even further out you could could sort of add some more cryptographic advanced cryptographic Primitives like dkg threshold signing and basically enter sort of the DVT uh distributed valid data space but the key here is right we have usually have like

this this key hot on dis to show up for consensus duties right um and sort of what we are going to look at over the next uh few minutes is sort of this in between layer as you could say where we would try to uh put a remote signing software inside a hardware enclave and and so sort of the tldr um to to sort of uh make you aware of and what validating from Hardware Enclave even means is think about your like your generic Hardware wallet and um which uh which stores your keys like you generate a key inside this Hardware uh Hardware wallet and basically what we add on top of this is uh program logic so we add

some smart fun functionality here and this is in our case uh slashing protection rules so uh what we get is this nice system where we have protection not only at rest but also at runtime uh and sort of also what what's nice here is it's really tough or we get a system where it's really tough to exfiltrate the the generated keys inside but still are able to perform consensus duties from it um right as shown here proposing blocks or testing to them and so the original idea uh to do so stems from this uh e research post by Justin Drake uh where he B basically proposes a hardware based slashing protection um for liquid solo validating pools and

just to give you a very brief idea like what are the properties of Hardware enclaves like what are we talking about here so on a very very high level like we we have to think about uh Hardware enclaves or the specific Hardware enclaves here as some form of isolated encrypted areas uh of our CPU memory where which we which are supposed to be like uh untable and sort of we trust uh the code execution inside it so what we receive as users is some form of confidentiality and integrity guarantees um on the code and on the data running inside those enclaves um and basically the uh the hard the underlying Hardware itself sort of uh ensures that those properties hold and

just to briefly contrast this from from multi comp multi party computation systems like like DVT in a sense or more advanced uh cryptographic Primitives we get this or it enables us to sort of run arbitrary and very inexpensive computation almost at the native speed of the CPU which is in the in the staking context particularly interesting a sort of uh latency is a critical component right um so what I want to what I want to introduce today to you is the software called uh secure siner uh secure siner is this open- Source valid data remote signing tool um yeah adapted to be run inside trusted Hardware inside Hardware enclaves it's written in Rust

uh has been originally funded by an ethereum Foundation Grant and the puffer team uh puffer Finance team went on to develop this this tool and basically what it is it is a web 3 C implementation um adapted uh to be run inside Hardware Enclave so uh simply what it does is sort of you have your you have your Hardware Enclave and then you instantiate The Enclave with a remote signing program logic running insiders and what you what you also store and generate inside us is the Val valid data Keys themselves plus the slashing protection database and sort of it makes you communicate then of course in a sec secure manner with the rest of

your of your not deck um yes and the underlying Hardware technology we're using here currently is Intel s3x but then of course initial question that arises is what is secure about Hardware en cliffes anyways right uh Intel is the centralized entity um the tool we use here or the the the the functionality we use here is propriety it's close Source it's been subject to vulnerabilities in the past so the memes are obviously bad uh but then if you if you look around a little bit in the blockchain space You Realize like uh that um uh teams like flashboards for example heavily lean into srix for the encrypted M Pools uh in in SW for example we see block Builders uh being

run inside uh inside s3x Hardware enclaves we see liquid reaking pools like puffer sort of using trusted trusted Hardware uh for to to lower the trust assumptions in nodee operators plus we see it in ZK land for example with multi-pro and multi verifying systems um opting for sgx the technology so uh at the end of the day it seems to boil down to like trust the some trust assumptions of users and and sort of the the teams developing this and obviously from a staking perspect perspective it boils down to to your subjective uh threat model so if we were to make an argument for why we should sort of what for why

we would want to validate from Hardware enclaves we could uh think of them as a simply purely additive ring of defense like an additional layer to secure our signing Keys uh moreover trusted Hardware is widely available right everybody from us can get a hand on it if if we wanted to despite the fact that Intel has sort of deprecated uh sgx uh from the consumer products lines two years ago on the server side uh it's still widely available um and last but not least uh using uh remote signing software in a diverse manners so we have we increase our option space uh and sort of make our network uh potentially more robust in a sense

and very specifically like node runners or what what specific risk that node Runners can sort of mitigate and and potential benefits for them uh look like could be as follows right you as you generate a key inside a hardware Enclave um it only ever exists once within with uh within a unique Enclave so it's not possible to accidentally equivocate or double sign um particularly for home stakers or or or Keys protected not in data centers it's interesting that like uh as you're protected against Hardware wallet theft like the me mechanisms in place there also apply to key stored within um uh sgx enclaves in this case

think of uh critical consensus client Buck introducing like potentially 4y slashing rules like as you run uh untable slashing rules inside a hardware Enclave you immune to such failures and last but not least you to avoid uh any um sort of uh yeah slashing risks um as a cons consequence of a potentially compromised node or or um or a client accessing this node right so um you're immune to uh kernel level malware for example operating system zero days um Rogue staking uh provider or cloud provider employee scenarios Etc and what's pretty cool about it it's

solo solar Staker friendly right you don't have to be an at scale operator to uh to use this technology so uh that's basically what I did what I wanted to test so I got myself this uh slightly outdated um uh piece of Hardware which is s n right s3x compatible um and uh for the sake of the demonstration I I I I wanted to run uh the whole client deck on this on this underpowered device so I tested this on ephem test net aary test net um is this neat little short lift validat test net um which basically uh allows you uh or has very low uh

Hardware requirements uh since it resets every every week so there's not a lot of block history or State history um so yeah it it it fit nicely in my in my testing environment and then of course I use some some dock compos script to sort of run my execution client consensus client and valid dat client and sort of the secure um my client interface on the untrusted side of my knock and then from there instantiated sort of secure CER the tool inside The sgx Enclave generated my my key pair inside it generated my deposit data file inside it generated my voluntary exit message inside it inside it and made it yeah SEC securely communicate with the rest of my not

stack and right so no uh no staking gathering without looking at locks so what you can see here is basically the secure CER lock fire um telling us that or showing the lock that we successfully attested um on a family test net at a given slot in a given Epoch um with a key stored and generated inside um trusted Hardware inside a hardware Enclave so Tada right it works when main net um will still take some time uh so secure sign of the tool is still uh has recently been released right it's still an alpha uh codebase is uh still being worked on uh it reads review it needs audits um there are some UI and ux uh

improvements we need um uh feel free to get involved uh if if you want to uh what would also be nice is to get uh Hardware vendor diversity right we don't want to rely on on on in so it would be great to have uh AMD support at some some point in time or uh I I know that there's work to um enable support for for um AWS Nitro for example and then in terms of an Outlook um the the usage of secure Cina is complimentary with DBT so as you can guess you don't only have to uh necessarily have to store a full key inside a secure Enclave but you can store fractions of a key in it as well

so if you think back to the original diagram we can sort of think of uh adding or running or validating from Hardware enclaves being um like an additional layer even around distributed uh Key Systems yeah uh that's pretty much it uh it's that's the long form read of my uh of my experiences testing these systems um it's also included is a uh step-by-step guide on how to set up the testing environment I just showed you um and um yeah don't worry uh you don't have to necessarily uh own or have sgx compatible Hardware at hand to test this right in a dummy mode sort of secure

signer can run on as a pure rust app in in your setup as well so feel free to test it out um and yeah shoot me a message if you want and uh happy to take uh questions thank you so much Lis hi thank you uh two questions uh one is that is it the same as HSM uh and the second question is you mentioned the the network which gets reset every week what was the name again okay second question uh it's called

ephory test net and this is a public ethereum test net uh there will be a talk by Mario later this afternoon so I suggest you to to stick around and the first question was uh whether this is an HSM so HSM for stands for Hardware security module I guess um which is as far as I know again uh disclaimer I'm not a computer security re researcher but uh like um the the the the hardware Enclave or secure Enclave but not smart right so you only store your keys at risk in Hardware secure modules as far as I guess so in sgx is basically this technology with with uh widens in very simple terms sort of widens the the

functionality to run uh program logic uh also inside um inside a secure Enclave right so it's not just about data storage it's about um trusted execution any other questions oh okay well thank you very much l sa appreciate it thank [Applause] you