Leveling Up the TEE Attestation Game On-Chain

EthPrague 2024 · 1 Jun 2024 · 21:18

Oana Barbu explains why verifying remote attestations from trusted execution environments (TEEs) onchain is expensive: it relies on cryptographic primitives that the EVM does not support natively. The talk at EthPrague 2024 shows how her team drives those verification costs down by integrating zero-knowledge proofs into on-chain attestation.

Speakers

Topics

From EthPrague 2024, hosted by ETHPrague.

Holešovice Market

Transcript

[Music] okay let's continue and greet Anana barbu and she's going to talk about leveling up the testation game on chain Round of Applause please thank you um hi everyone I'm Wana and uh from automata and I'm going to tell you how we can um make the uh decision cost um cheaper on chain but um before I before I talk about the at the session I would like to

ensure that we both have the we all have the same understanding of what te is uh a te or trusted execution environment is a memory Enclave within Hardware that prevents on access to uh to the data and and code store inside it neither the operating system kernel nor the hypervisor can tamper with the enclaved me memory this is achieved by having the CPU encrypt the enclaved memory to protect his uh privacy and provide computational integrity and uh it also ensures that only The Enclave is able to uh decrypt its memory common implementations of

tees are Intel sgx uh and Intel TDX am amdv and AWS Nitro Enclave um we believe that t are U very suitable for blockchain applications um chances are that if you think about uh privacy and security for blockchains you are most likely to think about zero knowledge fully homomorphic encryption or um multiparty computation however despite notable progresses in these uh Technologies they of often come with high latencies complex implementations and computational

overheads and some applications um may not be able to tolerate this on the other hand U te do not rely solely on the Elegance of uh math but they are um faster cheaper and more practical uh and these characteristics make them very attractive for applications today um T's we can use these to implement um roughly all uh we can Implement in a standard Computing environment and um we do so with minimal overheads that usually come from encrypting and decrypting the enclaved memory uh at automata we leverage these

to build coprocessors uh t Co processors for instance we built the um coprs for rollups uh coover enhances the security of a rollup by independently Computing the state transition and ensuring that the state transition uh that the rollup is proposing is correct uh therefore if both the T coover and the rollup agree on what the state transition is then we can have more confidence that the state transition was um computed correctly however a fundamental challenge uh when we deal with t coprs or t Co processor in general is how can

we ensure that the application we interact with is indeed running inside the te uh it is uh essential that we ensure the legitimacy of a te before interacting with it to be able to accept the the result It produced or maybe sharing sensitive information with it so if we imagine a scenario where two machines um claim to be te is how can we how can I verify that the uh the the Integrity of the te before engaging with it and uh luckily we don't have to blindly trust we can actually verify um that the t is authentic and uh this is done using uh

remote attestation remote attestation is a security mechanism that enables the te to prove its identity integrity and configuration to another party by engaging in remote attestation uh any external party can verify the authenticity of the te and ensure it is running um trust software and configuration during remote attestation the te produces an attestation document containing details about its identi and configuration and this document can be examined by the verifier to uh check that the t is um following the established security policies and requirements only a legitimate te uh is

able to generate a valid attestation document and uh thus any malicious effort to impersonate the te will be detected so uh let's take a look uh at what the attestation document contains to understand why that is the case so the structure of the te um document might differ depending on what the what te technology is being used but all documents will have uh these three elements so the first element is uh is The Enclave Identity or the public key this public key is linked to the te manufacturer and its private counterpart is um inside the hardware and Only The Enclave itself can access it um um

besides this we also have the Enclave measurements um these are details about the Enclave State um including the software that The Enclave is running its configuration of firmware and others and lastly we have a digital signature that's produced using the te's private key and uh this ensures that The Enclave identity and measurements are authentic uh the next natural question is how uh how do we know that the public key of the te is legitimate and uh recognized by the te manufacturer um I'm going to use Intel in this example but a similar process applies to uh the other

te Technologies as well so um we we do this uh we ensure that the t t is legitimate by having a chain of trust linking the T public it to is manufacturer um in this case the chain of trust is an X 509 certificate um I'm not uh going to details of what um this uh x509 standard is but it's basically the same technology that allows you to verify that the website is authentic when you when you land on it uh and the the x509 certificate used by Intel uses the SCP 256 R1 algorithm

for digital signatures so if let's say we want to verify the attestation document on chain part of this verification will be to verify all the SCP 256 R1 signatures that are part of the x509 uh certificate and unfortunately the evm does not support SCP 2561 natively and um this operation is quite expensive to do on chain uh more precisely a naive verification of an uh Intel testation documents cost about 3 million gas to do on chain out of which half of uh is spent on verifying SCP 256

are1 signatures and considering how uh much this operation costs it seemed like a good idea to try and optimize it so we try to answer the question how can we make SCP 256 R1 verification cheaper we thought about using pre compiles uh incidentally SCP 256 R1 is um a popular curve and the pre compiles for it are being adopted at least on l2s but there are other cryptographic Primitives that are used in Te attestation which are not as widely adopted for example AWS Nitro enclaves uh uses elliptic uh the p 384 and Sh uh

384 for it's attestation document and we don't know if and when these pre- compiles are going to be widely available um so we also considered using rollups um but um a significant drop uh drawback of optimistic rollups is that they use uh fraud proofs and fraud proof have a finality time of up to 7 days and this is very a very long time for um waiting on a te attestation as I mentioned before one of the benefits of using te is their speed uh and being a having to wait s days to establish whether a te is legitimate is

a very long time and the ZK rollups also come with their own limitations U validity proofs are notoriously difficult and um time consuming to compute and uh they large limit the functionality of ZK rollups to simple transactions like transfers and uh trades however um zero knowledge is particularly useful for compressing computation so we decided uh to look uh closer at using zero knowledge to reduce uh computation uh the computation required to do on chain to validate the signature so um in instead of trying to verify the signature on chain we wanted

to offload uh this computation of chain and create a ZK proof uh that shows the signature has been properly verified uh this proof is uh sucin and efficient and um typical ezk uh proofs are uh fast to verify but um the question was can we build a ZK proof that is cheap enough to verify on chain so we tried a couple CP of approaches uh this is a summary we started with a baseline of 330 uh K gas per signature verification This was um achieved using daos

p256 verifier contract and uh we shaved a third of um the computation CA by using a basic ZK circuit and we F we were able to further reduce this cost by using aggregation and um with aggregation we were able to get to a to 120 K gas per signature verification so roughly what uh ZK basic does is we have a a ZK uh circuit we feed the SCP 256 R1 signature into it to produce a proof and then we verify this proof of chain on chain and um with

aggregation we have this aggregation circuit that uh takes in multiple SCP 256 R1 proofs and uh generates a aggregated proof that we later verify on chain um proof aggregation is a method um that basically allow several proofs to be combined together and produce a new proof that proves all the uh the validity of all the initial proofs so uh in our case um verifying the gated proof U costed um about 480k gas meaning that one signature verification was uh about 120k which is a third of the initial

cost but then we thought what we what if we can offload the whole attestation verification to a ZK circuit building a circuit capable of um proving the whole attestation document is a very challenging task so we did not do it ourselves uh instead we decide to use a z KVM uh for the task uh ZK VMS are uh specialized virtual machines designed to ensure computations are performed correctly and uh they're also capable of handling General computation so therefore all we had to do was uh write the RAS program that um verifies the attestation

document and the let risk Zer VM generate the proof for us and to our surprise verifying this uh proof on chain only costed about 330k guas so uh what this all means um we by using ZK VMS we were able to make the attestation uh t uh the attestation verification 10 times cheaper meaning that is that much cheaper to verify that we are talking to a te uh attestation is extremely important for the enabled applications so um this is quite uh good result but um Beyond this I also want to

share two more General lessons the first one is uh that abstraction is a very powerful thing and ZK VMS are General and perhaps not as optimized as dedicated circuits could be but they're more optimized than what most people can design uh the ZK VM logic is written by experts in the field that know the inside out of the of ZK and um it turns out that these um Universal circuits are more efficient than um dedicated circuits written by Layman um to put things in perspective as I said for our aggregation circuit we were able to

verify the proof in for 4 using 480k gas and that was just for the signature verification whereas with the um ZK VM circuit we were able to do everything in uh 330k gas and um moreover uh ZK VMS uh remove the need to learn complicated mathematics and cryptography uh that are required to design uh ZK circuits and uh the second lesson is related to the importance of using the right tool to achieve good performance and efficiency at automata we are generally in the te camp and our coover showcases how te can help U ZK

applications but this time around it was uh ZK that helped tees and uh generally we think that while ZK ands are seen as competing uh Technologies um we we believe that they are both useful tools to have in the uh in your tool boox um if you want to learn more about automata this our these are our socials um you can um there you can learn more about um our multi-prover AVS our t uh block Builder and um other projects um thank you for your time and um I think I can I have some time for

questions thank you very much yes uh if there are any questions please we still have some time looks like everyone is tired today so thank you very much a round of applause and uh at half past six oh there is a question great hello uh I just have a simple question um is is any of these uh decentralized or is like automat running all the the hardware for these Services how does it work is it a decentralized protocol so I'm not sure I understand the question can you if it's if it's

decentralized the automat protocol like does it take requests for for doing this uh trust te stuff yeah so U you have a contract that will verify the um at the station document and that contract is deployed on okay but but who's doing this is just automat the the company or are there other participants in the is it like a network where anyone can can participate how does it work I mean we just implement the the algorithm for verifying the station on chain but yeah once it's on chain is decentralized okay understood thank you hi um I just saw that you been

having a token since 2021 and um I guess I wanted to understand a bit more um how the token interacts and uh how does the token you know acrw economic value or trans transmit economic value in your ecosystem we currently we don't uh use the product that we have with our token so the this is currently deployed on arbitrum on SE um Sephia on the test net so we don't deploy this on our um this particular te that you've been yeah yeah this and and yeah and then the token

acru value from other things that automata has done in the past or how does that work how does the economic kind of incentivization work I'm to to be honest I'm not uh the most capable person of answering that question but um yeah I I think it's the product that we try to build maybe help us gain more popularity okay thank you thank and one more Hello thank you for the talk um so like for if the hardware manufacturers they have if they allow for um signature

scheme that are compatible with blockchains like Ed 200 559 uh will there any need to have ZK verification on chain we could just directly verify the digital signature schemes right yeah so you can do it directly on chain but because it's not supported you basically spend a lot of gas trying to uh compute the verification right right but but if it comes to be um possible then we don't need is right I mean I guess for aggregation ZK is still useful oh yeah absolutely like if let's say SCP 256 R1 is being adopted in the right in the AVM then you don't need to

do that you don't need to do the offload of the computation anymore right right but I I think aggregation still makes a lot of sense actually yeah thank you yeah yeah actually um you like once instead of verifying a s single at the time you can also verify multiple in the future let's say byting them yeah and actually so you mentioned that you have uh used um um how was it brisk zero or yeah right um have you tried with other more like um specialized circuits for like other more performing proving systems or just risk zero uh we tried to

use sp1 as well but okay we are still working on that oh okay cool yeah thanks thank you right good [Applause] [Music]