 Helo. So, first of all, you know, took that logo because I liked it and watched Padlock on it. So now we've got a bit of a secure background. Exactly. So who am I? Jared Henson, security architect at Control Plane. And here, as David said, just to discuss conceptually the security. Not deep down, having such a code base. I mean, from some of the presentations today I can tell it's already changed. So the security, some bits in here may be true as of maybe a week ago. Be here. So just to note, Web 3 can depend heavily on Web 1 security. So Web 1, I say, is the read-only web or syntactic. And that came from the term of programming syntax to interact at a lower level with just your standard read-only pages. So it was your read-write web. And also dominated by the big tech companies. You know, Facebook, Google, they're all dominated. Some people call it the social web. And then Web 3, which I'm going to say is our space right now, decentralized and that's moving away from the big tech and everything in one central place. Not the cult-like movements where people think they can do whatever they want whenever they want and get away with everything on Web 3. There's more to open up more doors and allow people to do more with less. So what do we know so far in security? I've separated it into four categories here. You've got the CSPs. CSPs, Cloud Service Provider. So you've got Google Cloud, AWS, Alibaba as your IBM. Should you touch it? So they provide decentralized services, not actually decentralized, they're technically centralized. Because underneath, they've got health monitoring, logging, self-repair, and they're doing a lot of stuff which you don't see, but it doesn't actually create true decentralized service. However, they do use secure enclaves. All of them do. They have the power to, they have industrial kit. Google make their own from the bottom up, the TPM chips and everything. So yeah, they're virtually centralized. Then you've got your Web 2 peer-to-peer. Your Napster, Nutella, your BitTorrent. For example, BitTorrent was an unstructured peer-to-peer, which meant any node could join, there was no structure. But now it's semi, it's hybrid, because they've added the decentralized data discovery mechanism. And also if you've ever torrented legally, you would know that there's trackers, and you can see and find certain seeds as well. Competitors. I'm going to touch on just one actually, Gollum. So Gollum, I've been in the space a while. They do compute over data. They do it distributed. They do apps on decentralized. And yeah, they've got a big base already. There's a lot of stats. I won't go into too much detail. However, they haven't got a reputation system either. They haven't got any verification system. In fact, it's just one-to-one. For a result, I could give them something that doesn't actually know it's true. However, they did have secure enclaves built-in using Intel SGX. So the implementation was ready. GitHub is full of some of their repos you can take a look at. But they decided not to spend more resources or money on it, mainly because Intel discontinued SGX for consumer CPUs from the 10th generation. So only your big players of industrial CPUs can, you know, industrial kick and start doing this sort of stuff. And I mentioned that just because I'll get end up touching your enclaves, SGX later on. A like Gollum is only public data, we as Bucky are, we're looking at potentially moving on to private data. And there's a lot of security stuff analysis I did on Gollum, and they're susceptible to DDoS on the central network. Exactly, it's not even fully decentralising the claim it is. There is a central network that acts as a proxy. So you connect to it and it networks you through and spam that and they're gone. Bakwiao, so that's why I'm here. At the moment it's a true unstructured peer-to-peer from what I understood. If it's changed and the architecture's changed, I'm ignoring it. And that's decentralising this, you know, there's big wishes to move to private data as well as public data, because it will open up a lot more customers. And getting it wrong is expensive. People ignore security, people get annoyed with security, it slows people down, but if it's incorporated from the beginning it doesn't actually slow you down because you've secured yourself more than trying to fix stuff. And, you know, as you can see, there are huge numbers. Most recent one upon was the running network, $624 million. And you see your total up there, you've got $2.2 billion. Or if you're all deep in Web3 now and you start to use Ethereum as more of your coin of tracking, that other guy, I added it. But, yeah, the past two months, $977 million has been taken. All because of really, really silly, silly security mistakes. In fact, Badger, Dow on there, $119 million, that was actually a gooey problem. And there's something to note. And, yeah, just to say first, actually, this should be a discussion I'm hoping for like the hackathon or maybe some unconferences. There's a lot around security we need to discuss. But with Badger, that was essentially a cloudflare problem. Somebody got access to their cloudflare, adjusted some keys and essentially did some called ice fishing. And essentially anyone visiting their website, they're told to connect their wallet and really they just gave all their permissions to somebody else and siphoned. So that's again a supply chain attack, something from Web2 that Web3 needs to take hold of. Yes, so examples of some Web3 threats. I won't go through all of them. I just wanted to put some up. Some of them you may not think are relevant to Bacchial, which is true, maybe some price oracles. But in the potential future, where we look at smart contracts, that's when a whole different attack landscape opens up. Griefing, however, and infrastructure are more likely to happen with Bacchial, especially griefing at your malicious jobs, your disgruntled nodes, ransomware. I put ransomware on it, it's an interesting one. Ransomware on the blockchain has not actually been seen yet. It's been seen in a way where people have used smart contracts to pay ransomware providers as a service. So if somebody manages to get crypto payment to the crit, that smart contract says the owner of the ransomware will get X amount and it's an easy way to hide. However, could Bacchial be abused to use their network for malicious compute? For example, how would you detect that? How would we stop that? Can't you switch it off like you would in normal situation? Yeah, it was... Can you run malicious compute nodes that way? Well, in this sense, when I was talking about the ransomware, I meant using the power of the Bacchial network. So using other nodes to do malicious activity. Wherever that seat is, you know, command and control, you could do data extultration, you're processing, you could wrap it around Bacchial so many times in a similar way that you can wrap, stall on Ethereum through Tornado and lose its wallet. Modern tech stack, you're compromised, no matter what. So I'm going to go very high level in light. There's a deeper report. This is more of a high level presentation on it. So cryptography and confidential computing. I'll just explain to you that there's always proof in a very highest level. Say that I've got a green ball and a red ball, I'm colour blind and I can't tell the difference. And I'll be asking, let's say, in front of me to tell me, as I have my hands behind my back, which one, you know, is it the same or is it different? I still won't know the colour, whereas Luke will be able to see the colour. I assume he's not colour blind as well, otherwise we will be in a loop. And then I will somewhat know that it's different. They're not the same, but I won't know exactly why. And that's a very high level to acknowledge proof. So I'm the zero knowledge and Luke would be the prover. So compute over private data. Homomorphic, functional, and what I've named authorised encryption, which is something to look into again, hackathon. I want to discuss it. So you're homomorphic, what we could use it for. You know, you're really sensitive, health records, intelligence agencies would definitely want to use stuff like that. Medical hospitals won't start putting up client, patient data, especially depending where you are in the world. I mean GDPR would cover so much that it would be screwed if you were processing that unencrypted. You got functional, so it's okay to know the answer, just not how it's operated, what the actual data was, and the algorithms running on it. And then authorised of name, which is semi-private, hide from casual viewers, and it's okay to compute to see. So homomorphic encryption for bacchial, examples of jobs being run of homomorphic encryption, could be part of the github repo, but I believe it should be left to the user personally to take control of homomorphic encryption. We should be able to provide the functionality. We should be able to provide some example jobs, some examples of how-to's and guides. Ultimately that should be up to the user. We shouldn't take on that security risk, not all the logic. Functional encryption for bacchial, so that's a private key. Let me explain functional a bit more. It's used in spam filters for email, so essentially it's a private key that has a function built in within it. So let's say everyone's salary in here is in one spreadsheet, and I wanted to access my salary information. None of you want me to see all of yours. So I could provide a private key based off the master key that has a function to decrypt only Jared Henderson and all my details. I still wouldn't be able to see anyone else's. So that's how, for example, Gmail will check for spam. It doesn't see the content. It just provides a function and gets a boolean result on top of whether it's spam or not. And authorized encryption. So this is semi-academic, but I think potentially possible after being introduced recently to LIT protocol. I think that came through David actually. And they have essentially decentralized key management system, and it's based on Andor rules. For example, if name is Jared and has wallet address 123 and, I don't know, doesn't own an NFT, for example, I could then get a key. And the way I thought this could be used is we could have encrypted data from all customers on Bacoial and use something like a decentralized key management system to provide the key to the compute node. So the compute node will request the key. It could check Bacoial could have a module to check. If the compute node won that job, it's got the correct user, and then it has access to this data. It can pull it down and decrypt it, do the work. But it could also reverse and do the encryption, pull the encryption key back into decentralized key management system, and then the user will be able to decrypt their result with that key, essentially hiding it end-to-end. That would definitely require a bit of a discussion hackathon. It sounds simple, but it's not. That's essentially what I meant by authorized encryption. And we've got secure multi-party computation. Again, another simple way to explain this is there's three people with their salaries, your Alice, Bob and Carol. What Alice will do, she'll give, keep 50 to herself. She'll give Bob 30, Carol 20. Same pattern for Bob. Bob will give Alice minus 80, 100 to himself, and Carol will get 180, and that will add up to their total salary. At the end, it's all added together, and that total amount is divided by the amount of users, and then you'll get the average. Unless Bob and Carol work together, they can work it out, but on a bigger scale, it will be much harder to deduce these values. It's quite a simple way of getting a result, and you may have heard this in the millionaire's problem. Six millionaires, they want to know who has the most money without saying how much, and it's the same thing. Give all their money, and the answer will be, I don't know, Bob. Trust, the execution environment, important piece for Eric and Bakial's future, both for the requester and the compute node. So in this case, the host is the compute node, the guest is the requester. Why? Because you're running other unknown compute on other people's infrastructure. It protects the requester and the compute provider. The host, essentially, like it's on slide, doesn't trust the guest, nor does the guest trust the host. Complete zero trust. They don't know each other, don't like each other, but they're doing work together. And why is it... Sorry, trust execution environment. You can see how much it removes. Each extra layer on the left-hand side, which is traditional, adds extra room for security vulnerabilities, whereas in your trusted execution environment, you essentially got the three, the CPU, that middleware to interact, and then the application itself. So you can do attestation and cryptographic proof that a trusted execution environment is run. You can also check current state of memory and registers to make sure it's zeroed out, so there's no tampering done. And keys are baked into the hardware in manufacturing time by the vendors, and the public key is stored in the vendor's database. And what you could do is then use that to check if a compute node is running a trusted execution environment. Check is not tampered with and run the job. Now, conceptually, you could have two types of compute nodes. You could have one that runs on the firecracker ignite the docker, or you could have people also register themselves as a T compute node, and they can provide this sort of execution. And linking to WASM, so when I was first looking at the security back, I was only aware of the firecracker ignite and the docker, but now with WASM, there's actually a red hat project called NRX, and they essentially do this for you. NRX run a WASM binary. It does all the checks locally, checks the keys, if there's something wrong with the enclave, it won't run. It just won't touch it. There's probably possibility to use an NRX API to remotely call and run. However, that does open up network communications, and you start to get into the centralised area of decentralised, where people create decentralised apps and tools, but then suddenly they get centralised by adding one feature because it's a fail. There's also a tool called T-Line. They can do TPM attestation, and T-Line's mission is to make TPM technology essentially easily accessible, and it was invented for use on remote machines and devices on the edge. And there's three parts to it. There's a verifier, a registrar and an agent. The verifier verifies the integrity state of the machine. The registrar is a database of all the hosts and the TPM vendor keys. We could do that in a decentralised way. It depends. You could use a blockchain for that. You want a big database, if you think of it at a very high level. And then the agent, which is deployed to all these remote machines and checks that it's constantly secure. There's no leakage, and then it will only release secret keys when it's done its pass. Yes? Two questions. First is, with Intel, dropping out, is there like, across the security community, is it assumed that T's will continue, or is it like folks are mostly seeing that go down? I'll move to the next slide. You've got Microsoft, IBM, Google, ADS and Red Hat and Arc are mentioned. Everyone's playing in this space. Encrypt data and recent transit is solved, but encryption uses them. You can see the big players playing it. There's a lot on it, the open source, a mix of open source and non-open source. ADS is actually the only one that's not a member of the confidential computing consortium where the rest of them are. And that's because I think ADS user and specific stuff. It's no SGX, it's no SEV. But the interesting one about Red Hat and Arc is because it does support wasn't binaries, natively. So there's a threat modelling piece. This is the bit that drove a lot of the work that was done. This is the high level conceptual diagram that Luke and Kai displayed. They had it a bit lower down. This is the highest we went. You've got your requester, your compute, your job, your bidding. The most simple. We focused all of our threat modelling on this model, and the current potential threats identified have been separated into those following six categories. To iterate, we didn't come cover the code base. It wasn't in scope. And again, a lot of this, we should be able to flesh out in a hackathon. I wrote this presentation in a layout in a way that we could sit down and smash together because everyone has their own skill sets to be able to bring a lot more. How's that looking? It's a bit small. The top right is the diagram and the bit highlighted in red is to visualise where we're covering here. This is the submission of the job. We don't know everything yet of how someone will submit a job. But conceptually, a user might be able to spam multiple. Do we know if they're going to pay first or they're going to pay after? Is it going to be like Gollum where they actually set out in Jace or Yamel? The amount they'll pay per minute of processing, I think it is. So, do we have an escrow and store that money first? How much do we take? What happens if there's price changes? There's a lot a user could do with funds or the price of the funds. And then, schedule a breakout is an interesting one. It's the supply chain. A user in perlals and attacker to breakout. And that can link back to your traditional injection attacks. I think a sequel injection is still around now. It happens all the time. These things can still happen just because we're in decentralised doesn't mean everything changes and we're all secure. It's a misconception actually that people think something utilising blockchain, in this new web 3 space, is actually secure. There's a reason why so many things are getting hacked and the amount of money is being lost, which I showed at the start. Bidding on a job. The user is submitted now we're bidding. The compute node is bidding and deciding whether to bid on that job. This one is interesting. I mentioned secure MPC in a control for quite a few of it because are the computers going to see each other's bids? If they can, they can start doing undercutting. They can or you can impersonate other nodes. How do we identify if the compute node is correct from that provider? Are we going to use some sort of cryptographic pseudo identity? Are we going to use other wallet addresses links? If the wallet address is linked nothing stops you from spinning on up. I could create a metamask wallet in about a second by just clicking on the extension and a new one. And then also false bids. Using let's say I compromised some node and I started creating a load of false bids to severely under bid on a lot of work will actually cause that compromise node to lose money because the compute cost is a lot more than what the user is paying. And another one on supply chain. This is a massive key one as well. Simshow Badger was knocked out. So if the source code is modified never accept a bid. How would you do that? You signed commits and GitHub functional dynamic testing and signed release binaries. So I left on to last because Gollum again I'm just mentioning Gollum so we can keep comparing security in something they lack in actually but signed release binaries will allow the requester or the compute node to run and know that the code has not been modified because if we put the security mechanisms in the source code nothing stops them from downloading it and removing that code and modifying it. I sat down for a while trying to work out how to stop that and I could at the time anything of these signed release binaries with this open source state technically 51% attack applies to that if there's one compute node that owns 51% of the network. That also becomes a verify issue but I'll hold that one. Request impersonation. That's also similar I mentioned for the user bidding. Lack of funds again it's another one I think it's quite important if the user doesn't have enough funds either someone's going to be screwed and it's probably the computer not being paid so how do we do that we're going to use escrow are we going to do some sort of zero knowledge proof so we don't know how much that user has no one wants to display here is my bank account but I can afford to buy a bottle of water you'll be able to provide some sort of proof yeah I've got enough money but you don't know how much and it's this sort of the implementation is what I see going forward and the the user so denying all bids is an interesting one so the user never accepting a bid from a compute node so we know the compute node gets may lose money if it starts being griefing what about the user well if I put something on there and just constantly deny bids it doesn't really cause harm it's just very annoying and if it's on a big scale demoralise compute nodes and people will leave and like I've got some questions is bidding optimised for better compute or cheaper cost exactly exactly and that question there bidding optimised for compute or cheapest cost that also links to how we can have compute nodes with trusted execution environments is there a difference can you pick, can you choose, is it random there's a lot that will cover that execute the job so yes one because this is the second slide it's almost everything goes wrong there's one not on there and that's for example let's say I've instructed a compute node to do some work on a large data set but that data set is updated but not very much and I use the same compute node because they're trusted I just like using them and they can do a good price what stops the compute node spoofing the previous evidence of work because you could say the computer has done the work but he's just using the previous evidence of work for the future ones that starts to ruin that verification method that's something I've thought of and discussed with a colleague doing this work and it's really good in fact I didn't think of it, he thought of it I won't take it, it's under there false answers compute node providing false answers verification system we've gone over quite a few times today reputation system deterministic jobs of a large quorum of nodes but that's expensive he was going to pay for it retaining job data so that's a private data issue obviously with public data at the moment it's not too big of a scary risk for us however with private data that is a risk and again to mention Gollum they actually retain data for 30 days on each compute node in the case that they're going to do another job on that data and then it's automatically cleaned obviously that's something we will not do they only do it just so they save the better efficiency on detaching and detaching images any of the big ones on there sensitive algorithms so it's not just the data what if I'm sending a sensitive algorithm that's proprietary to run a backyard what stops compute nodes from seeing that algorithm and stealing that and that's again homomorphic encryption probably 10 years away from really fast efficient you can do it it's not like you can just do it really quickly it will take ages for big data sets so again trust the execution environment being able to put that data into somewhere that is separate a compute node should not have access and read or write and we should also check that it's zeroed out memory and registries beforehand it's like two of execute jobs so sensitive data again that's the PCI DSSG there's mentioned legal content what we're doing now we're going to put it into terms and conditions go policy wise terms of use similar to ADS that even have terms of use covering zombie in apocalypse and if you've seen that it's actually in there content inspection I know Dave you said it's separate and already covered I'm assuming it might come under that itself going malicious jobs again malicious network usage we could also use in executing jobs zero knowledge proof to prove that you've actually computed the job without sharing the results that others would copy and that covers a copying answers I know you already mentioned it kindly in your presentation with the encrypting it depending on speed or options obviously you can use that built in or zero knowledge proof or the question we put forward is are the results only published once paid and that saves that encryption piece for example or wherever it's stored until it's paid then the results are shown and then it removes that copying that actually reminds me that's similar to the ransomware one I mentioned of using it for malicious network but I could also let's say I have a huge zombie network from a remote administration tool a rat I've got a load of hosts from people I've infected since 10 years ago stay quiet what happens if I somebody call a bacchial computer node and every single one of them is that an immediate 51% attack is that who's liable there's a lot of things to cover on that one and that's where you can do that attestation on the trust execute environments with the keys built into the hardware and the proof of ownership using zero knowledge proof again that pseudo anonymity don't know who I am but you know it's mine and it's legitimate verifying results and another one's zero knowledge proof it keeps coming up without giving away the answer so for example if I was doing the red and green ball behind my back which is a red ball so never give the answer it's zero knowledge proof if that's contested then we know there's a false answer or a wrong answer lack of funds is it repeated again the user doesn't have enough funds for the jobs at the time of payment how's that linked in with the verification is there payment there what if they never verify if it costs to verify why would they what if they just use get the results and never reply back it's probably better to pay per processing and if that payment isn't being paid just stop at least the computer doesn't lose out the only person who's out there is the user and yeah oh an annoying griefing one is withholding verification just outright not verifying in order to prevent payment to the computer node so they've done the job and they got the answer but they're not paying the computer node because computer node relies on that reputation or verification payment so payment is hard one to cover primarily because we're not touching the code base there's no smart contracts involved yet so if I had enough power or enough funds or I had access to some sort of whale client let's say Elon Musk was my friend I just have to have him tweet one thing about Bakuow to make it go up or down and essentially I could pay less to get more done or end up having my tokens worth more once I've been paid by the user and they've essentially then overpaid I know the market changes but obviously it's manipulated that quick you have that slippage it's similar to how price oracle attacks happen an empty wallet the job request has an empty wallet before accepting bids what happens there because then if they provide false answers they usually have a cost they won't just lose reputation they'll also get fined essentially if it's empty how are you going to find them do we have to do a payment escrow on the side again how do you know people can afford jobs they're requesting same things keep coming up so in summary covering those high level from zero knowledge proof homomorphic encryption function encryption secure multi-party computation and trusted execution environments so the protocol that's the interface and the interactions smart contracts all that lovely stuff with zero knowledge proof yeah it's applicable first proving they have enough money and how much secure multi-party computation that can include your blind bids a computer can be saying how much computer provide in X window at X price for example if that feature is allowed if people can walk away and accept bids based on some sort of criteria SMPC or A provide privacy on the bids but also allow that extra feature to automate accepting bids they can also cover sensitive information and allow the Bacchial system to automate it and that's really important for protocols on web 3 because it allows you to step back we should be able to leave the Bacchial network and it doesn't fall down obviously not leave the company and disappear but we should be able to step back the implementation so that's the go-lan code not much done really I've already mentioned the user can remove it as Kai said he should be able to join so he can't really just willy nilly sign up with a signed binary you can maybe use your knowledge proof to prove that it's the Bacchial code base you're running as a compute node and definitely yes to trusted execution environments so protecting the compute node from unknown jobs running on the infrastructure and consumer jobs this one is important it's applicable to private data we don't really need this any of this actually in the case of public data but zero knowledge proof can provide that verification a job is done or is correct or it's a fail homomorphic and functional encryption so that allows to process the private and semi private data again that links I haven't put the authorised encryption in there because we coined that term ourselves but that links a lit protocol idea of having that distributed key management decentralised sorry and then utilising that with Bacchial to encrypt and decrypt customer data on compute nodes sending it back and forth so it's not homomorphic it's not functional really but it just adds that extra layer of security from side channel attacks and protecting both the host and the user and then trust execution environments it can somewhat protect data and algorithms from the host and the compute node and that is the job so all private code like I mentioned allow us to run these sort of jobs but provide some sort of security to the user to know that their algorithms and IP aren't going to be taken let alone the data sometimes the algorithms worth more than the data is gone and that is me that's it