Welcome to E to E to E to E to E. Hi everyone, I'm Ben from Fireblocks. I lead a confidential computing infrastructure at Fireblocks. Uh with a show of hand, anybody is familiar with confidential computing trusted execution environments. Okay, some of you h so a little bit about Fireblocks before we begin.
We founded 2018. We have a lot of numbers here. Not going to go over everything, but uh the main thing you need to know is that we are wallet infrastructure company. We provide infrastructure for clients like Revolute, Bank of New York, Melon, Moon, etc. Uh we transfer a lot of funds as you can see, $6 trillion of volume, over 70 billion under management.
And that means we are pretty paranoid about security. And you know if you're pano being paranoid doesn't mean no one is after you because we're really under the most sophisticated tech vectors. We assume very sophisticated threats. Let's start with the maybe problem we are trying to solve. The problem is that to sign a blockchain transaction obviously you have a private key.
You need to keep this private key very secure because if I have control over your private key, I can just funnel the funds to another account. H if somebody like I don't know North Korea would get hold of of your private key, they can just take all of your money. That's what basically happened with the buy bit hack or no ad they compromised the UI by other hacks used to just take the private key and funnel the funds to another account. So obviously we need a really secure private key and that's what we are doing at Firebox. We help our clients secure it.
Uh the threat model is basically nation state level adversaries. Uh we assume privileges on our virtual machines. We assume the attacker can dump VM memory, dump disk data, snoop the network, the traffic. Everything is fair game and we still need to protect the against those kind of threats. So let's start maybe with an a solution on how to secure the private key.
Uh first we can just store it on disk right but on in our thread model somebody can just take it from this because we assume they have full control over the virtual machine and and our cloud infrastructure. So maybe a little bit more elaborate is to encrypt the private key and then store it on disk. But it's a chicken and egg problem, right? because maybe I store the private key encrypted but where do I store the encryption key? It's like we are back to square one.
So we basically what we need is a root of trust is a place where we can have the encryption key or something similar uh that is very secure and allows us to then store our secrets in a way that an adversary with the assumptions I said uh full control over of virtual machines isn't able to compromise. So we have alerted solutions. So there's no silver bullet in security. You can't have one size fits all solutions. And I'm going to focus on confidential computing.
But also a little bit about our MPC algorithm. H we have additional controls on top of multi-party computation and confidential computing like a policy engine Firebox network. I'm not going to get into those parts of the solution. We're going to talk about MPC next and then confidential computing. So as I said private key is a problem.
So the first step is to get rid of the private key. Uh we use a cryptographic algorithm from a family known as multi-party computation that allows us to basically split the private key into several key shards. Each shard is separate. It's randomly generated and most importantly it's also created in a distributed manner. That means that if the three of us want to sign a transaction together and generate a private key quote unquote, we can all generate a random key shard using some protocol I won't go get into.
And those key shorts themselves uh together are able to and I'll tell you how in a minute uh to sign a transaction. So there's no private key. We have three shorts. That's what you need to remember from that slide. Uh the key shorts are managed by cosigners.
cosigners are cosign because they sign together are just the microservices we developed that control those key shards. So we have three key shards and three corresponding cosigners. H the trick is that one of the cosigners sits with our client. So for example euro or moon have a cosigner and they manage that cosigner. It's separated from the firebox organization.
So Firebox have two shards and the customer has one shard and only if we close the circle and communicate we can sign a transaction. So if Firebox is compromised it's fine because the client has a key shard that is not accessible to us and if the customer is compromised it's also fine because we have the remaining key shards. So that's the first layer of the solution. H the cosigners operate with zero trust. So even if there's one or two malicious cosigners that don't adhere to the protocol, it's still fine.
We can't sign a transaction and the shards themselves don't leak. They always stay secured with the cosigner and even if there is a malicious cosigner in the system, the the honest one doesn't leak their key chart. So basically when we want to sign a transaction, the three cosigners communicate over a few communication rounds. At the end of this communication round, they like ping-pong the transaction between them, the transaction gets signed without any other cosigner learning anything about the key shard and the secret of the other cosigners. So there it's a full uh zero trust setup between the cosigners.
H another nice uh thing about that is that it allows us to give our customer direct custody. What that means is that they don't need to trust Firebox and put all of the key material with Firebox. customer uh secures their own key shard and that means they are always in control of their funds. I mean they can't firebox can't sign a transaction. We are not a custodian.
We only we always have one key shard at a customer. Uh okay. So we splitted one private key into three key shards at the first layer of the solution. We still need to protect three keys like we need to protect even more things. Now as we said where do you store it?
If you store it on disk somebody can just take it from this in our threat model. So what we need to do confidential computing to the rescue uh it's confidential computing basically it's a family of technologies AWS has one Intel AMD I'm going to have a slight bias for SGX in this presentation but basically those principles are similar between technologies. So confidential computing is a family of hardware backed technologies. So we have some hardware that gives us extra capabilities that I'm going to go and explain in the next slides and each the they give you an ability to run custom software in a memory region that is called an enclave. So what are enclaves and we can run the cosigner in a memory region that is encrypted by the CPU.
So, Intel generate in the CPU some random key and then we load our software into that memory region that is encrypted with that random key. The key only lives uh uh temporarily while the inc enclave is alive. It's not stored anywhere. it's only stored in the CPU and that gives us a really good integrity and confidentiality from malicious actors including the kernel itself or anyone with root on our VM because the memory is secure and protected by a key that resides in the CPU even if an attacker gets root access to our virtual machine they're not able to either change the calculation performed by the cosigner because they can't write to the encrypted memory and they can't snoop the memory Hardware keys is the second thing that we get from confidential computing on from Intel SGX. Erh.
So what are hardware keys? So we have the cosigner running inside an enclave inside a trusted execution environment that is protected by the CPU. We have a special instruction that allows us to get an encryption key from the CPU itself. Each CPU goes out from the factory with different randomness embedded into it. So different CPUs will give us different encryption key.
Also another nice thing is that different applications will get a different encryption keys from the CPU. So our cosigner is going to be able to receive an encryption key from the CPU inside the enclave where the memory is encrypted encrypt for example the key shard and then store it on disk. So then when a malicious actor take a look at our disk they only see encrypted data and the encryption key is stored in the CPU in a manner that only the cosigner is able to retrieve it. And the last point I want to make is remote attestation. Remote attestation is another feature of confidential computing that basically once we load the software into an enclave into an encrypted memory region the hardware itself is able to give us certain guarantees about the exec about the software that is loaded into the enclave.
So for example the in the the identity of the cosigner hash over the memory of the cosigner hash means that basically it's the loaded binary the loaded software is getting hashed so we can know the identity of the software that is running inside the enclave that report generated by the CPU is signed and then an external party can verify the cosigner when it communicates with it. Okay. So, say I create this report with a special instruction. I can prove to an exter external entity that I'm a honest cosigner because they can just examine the the attestation report that contains the identity of the application and some hardware guarantees for example that it's running inside an enclave and then only the external party can communicate with me because they passed an authentication by verifying the report. So tying it all together memory sniffing say I have root on the machine or some elicious actor is root on our virtual machine they won't be able to sniff the memory because uh the memory is encrypted and the encryption key only resides inside the CPU okay our application is loaded into an enclave and even if you have root or your kernel h you control the kernel you can't sniff the memory of the application that means we can process the key shard safely or any other secret inside the cosigner at runtime because the memory is encrypted.
In order to have persistent storage, we can use the hardware root of trust in the CPU to generate an encryption key that is only uh can be only generated and retrieved from the CPU by the cosigner. That means that even if you have amnicious actor that's running a separate enclave on the same machine, they won't be able to get the same key. So we take that encryption key and we can store the key shard on disk safely. And the last thing we get is encryption in motion. That basically when we try to communicate with a different entity, for example, another cosigner, we are able to first prove our identity that we are a valid cosigner running inside an enclave using the attestation report that is signed uh by Intel and then only then the external entity can uh confirm our identity and allow us to communicate with it.
If the attestation report is not valid, they can just cut the communication channel. So before or rather after setting a TLS connection between two parties, we can verify the attestation report and only then continue the execution. So that's it. You can try Fireblocks at this website. You can get a free sandbox account and if you have any questions, I'd be happy to answer them.
Thank you. Big thank you, Ben. Nice explanation on how fire blocks help a lot of u assets to be secured. Uh are there any questions? Yeah.
So what happens if keyart is lost? Uh explain law. So like this corruption. Yeah. So we have backups.
You can back up. For example, the client can give us a public key. We can encrypt the key shard with that public key inside the enclave and then export an encrypted version of the private key using asymmetric encryption. So the client will have the private key somewhere and they will be able to restore that key short. So you need backups for that.
Yeah, of course. Okay. Second question. So you if I understand correctly, you're using uh multi-party computation inside enclaves. Yeah.
But why wouldn't it be enough to just have like simple um protocols because enlays are secure you can attest them you know which problems are running so you can actually comp yeah I mean you could basically but we have several layers for example if we use multipartic computation we're able to physically distribute the key shots between different machines and also between us and the customer if we had the whole private key at one place one uh software has bugs if you have some vulnerability in your enclave. You don't want to have it to to it be game over if you physically distribute it the secret. So it's harder to put your hands on three key shots especially when the key shots relied in different organizations firebox and the customer. So you need to compromise two organization three virtual machines three enclaves it's harder. So it's just a lay solution.
Okay. Um and the last one um yeah when you said the techs are talking with each other how do you prevent man in the middle attacks? Yeah. [Music] So using remote at the station we can always verify who where we're communicating with because the cosigner can produce an atustation report that is signed by Intel or by the with the help of the CPU and only then we said okay it's a valid software that is running inside SGX enclave. It's a cosigner that we recognize because you can verify its identity in the remote in the at the station report and only then we allow the communication to happen.
So you can always just you know verify and then proceed with the communication. Yes. For more questions you can meet up with Ben and ask uh your personal questions. Um like
Automatic transcript — names and jargon may be misspelled.