 I think we are going to start soon, but before the main event, I want to go over a couple of administrative items in the Hyperledger Identity Working Group. The first thing is we are bound by the antitrust policy of Linux Foundation and hence anybody who is joining this call is expected to abide by that as well. The details can be found in the agenda. The second thing is we have a Code of Conduct which says that we treat each other with respect even when we are disagreeing with each other or even when we are agreeing with each other. It doesn't matter. Please respect the other participants and treat them as you would be treated yourself. Before we start, it looks like there are still people coming into the room. There are already 14 participants, so I would rather wait just one more minute. I see some familiar faces, some who are not familiar. In any case, I'm going to drop the agenda link in the chat so that people can put in their names on the meeting notes as having attended. That's important because we want to keep track of people here. Of course, if you don't want to be on the list, please let me know anyway. I wanted to take this opportunity to welcome Rebecca or Ribi, Aspla, I think I'm saying it right, I hope, and she is here as a project director of project management from Unbound, Unbound is well known for being the pioneer in MPC because Yehuda Lindel, who I occasioned to listen to, did present in several contexts the greatness of MPC for custody and transfer of assets, especially in an enterprise setting. I believe it can be useful also in other settings because it allows some amount of delegation, and so Ribi is going to talk about many of these aspects. You got the email, so let's welcome Ribi to do the presentation and hopefully she will share her slides and we'll get to record it and make it available. Thank you. Thank you, Ribi, so much for the kind introduction. My name is Rebecca, the abbreviation is Ribi, so as you feel comfortable and uncomfortable with both, thank you everyone for taking the time to join Good Morning or Good Evening wherever you are. I hope you will find value in this presentation, we will of course share it afterwards in an offline manner. I'm sure Ribi will help me understand how I can share it with you guys, and assuming that you do see the slides, I will begin if that's okay. Can you see the slides? Yes. Okay, so I'm moving on. Thank you. We'll be moving on to a presentation mode, and I do apologize, I'm working from home as most of us I think are these days, so there will be background noises. I do have a dog that is often barking, so apologies for that in advance. So we'll focus today on IoT ecosystems, specifically blockchain type of IoT because there are different IoT ecosystems, and we'll talk about the challenges that this specific ecosystem is working with or is challenged by, and how MPC could solve these challenges as opposed to say I would say different methods. But firstly, very briefly, I just two slides of things about Unbound Tech, very privileged to be working for these guys, these are Professor Yuda Linda and Professor Nigel Smart. They have been the co-founders of the company, both of them are academia people. They have been working about or of multi-party computation for the last 30 years. So that's quite a long time to work on something, and have been able to get through a performance type of breakthrough about six years ago, being able to shorten the performance time of multi-party computation from minutes time to many seconds time, therefore opening the door to applicability, let me say usage of MPC. Their initial idea, by the way, was to secure airplanes with MPC, but we found together for the last six years that the use cases are various, numerous, starting from, you know, even creating the HSM, which is more secure than hardware HSM, going through code signing, protecting digital assets, and today we'll focus specifically on the use case of blocking specifically IoT kind of ecosystem. Unbound, this is its brief history. I wouldn't dive into this today just to let you know that we've been around for about six years now, growing day after day, very proud of the type of customers that have trusted their assets with us, whether these are data assets or financial assets. We have customers such as SteadyBank, Goldman Sachs, IBM, McAfee. These are just a few of the names that I can mention, liquid in the blockchain area. There are many more names that cannot be disclosed, but we're very proud of our enterprise-grade type of customers. One can only imagine that these types of customers run through very vigorously, I would say, pen testing and security checkups before they sign with any type of company. So, although the product is rather new, it has been out there less than 10 years, the technology is very much trusted by those enterprise-grade customers. Moving on, so now we dive into the stuff. No more, I would say, marketing of the company itself. So behind the scenes, MPC, and this will be the foundation of our talk today, and we'll see in a minute why. So behind the scenes, MPC is pretty much taking a key, pretty much. It's not that simple, but it's pretty much taking a key and generating it from scratch in a distributed manner. So the key does not exist as one entity all over its life, like a full generation, to usage, to suspension, to revocation. And the number of shares could be unlimited. In this very simple example, we could see five key shares. You could see that the key shares could be on any type of device, could be a mobile device, could be a laptop, could be a server. We're a platform agnostic, we're a device agnostic. And therefore, the possibilities you can start imagining what you can do with such, I would say, an ecosystem of multiple key shares that could be leveraging their power together to sign one transaction. This transaction could be signing data transaction, financial transaction. It doesn't matter. The whole thing is that the key does not exist as one entity. This is evolution-wise representing, I would say, the next step as to if one would know with blockchain specifically for the context of this call, starting with one key that was once kept or still is kept in HSMs, moving on to multi-seq, which are multi-pod keys shared with different parties, but with their full manner keys, full entity keys, on to MPC, meaning key shares. And it is not me saying so, but actually Gardner is saying so. That MPC is going to be the main, I would say, best practice type of security means in the next five years for blockchain applications. So this is really interesting, not my word, but actually Gardner's word. Now diving into IoT and specifically blockchain IoT. So this is where we'll start diving more into the details. So the starting point, of course, is the fact that we're surrounded by these wearable and devices that are sending data and receiving data all over the place. There's a projection of 10 billion more devices coming online in the next four years, and lots of data flowing around all over the place. Now this is very different from the situation there was 10 years ago, and certainly from the situation that will be 10 years ahead. This is interesting because many of the devices that are out there already are brownfield in the sense that they operate with very minimal power or processing power and still one has to secure them or rely on them once trying to operate. Now, obviously attackers will exploit and are exploiting these, I would say, vulnerabilities. And here are just a few examples of what you can do in order to attack an IoT device. This is not the focus of our talk to data vulnerabilities themselves, but the way to protect them. But you can see here different types. And I think this is the important thing maybe to emphasize various types of security vulnerabilities that an organization or a blockchain infrastructure of IoT ecosystem must take into account when designing such an infrastructure. Now the type of protection that you need could be defined using these four types. If you could look at it, so you have the need to secure the devices themselves, the hardware, you need to secure the communication between the devices. Remembering these devices and data from one to another, specifically in the blockchain news case where the data should flow between each peer to another peer. There's of course the secure cloud where data goes on to and from to and from the cloud to the devices off. And of course the lifecycle management of the data itself. Now the little key icons were not actually on the original image that I have found. You can see the IoT analytics source credit is to them. But interestingly, many of these security I would say protection requirements do require secure key to be able to work them in a secure manner or move them around, move data, secure data. Whether it's data at rest, whether it's data transit, whether these are authentication of the devices themselves, the identity of them, or whether these are authorizations of messages moving around from one device to another device, to a cloud, to servers, wherever it is. Now how these keys are being protected today. This is becoming more interesting because today, most of the IoT devices don't have secure elements. You can actually distinguish between weak IoT devices and secure IoT devices. Interestingly, I don't know if you recall a few years ago, there was a very interesting impact on one of the largest hotels in Las Vegas. I don't remember its specific name. And the data of the various gamblers, etc. was stolen, a lot of data, one can imagine. And interestingly, the way that they got to the IT, to the servers on which data was, was through the term mayors of the, where do you keep the fish? I don't remember just how the words, like those big fish tankers in those large Las Vegas casinos. So those terminators are weak IoT devices for that matter. And the hackers were able to reach the cloud servers, the data, the IT and the data of the various gamblers and the casino data through the terminators of these fish tankers. So we can see that there are weak IoT devices and these are actually the majority of them. And there are of course the secure IoT devices, but the ecosystem is the one that we should care about because wherever you go into a home, a city, you have to deal with both types. Now the weak ones don't have secure elements. They're actually working on very low batteries or very modest processing power. And their battery is expected to last at least two years. So you don't have to replace those. One can imagine how difficult it would be to replace batteries all over cameras for that example. So one would have to create a cryptographic type of security that is powerful enough, but then again, not heavily consuming processing power. Now, this is very interesting as the fact is that currently obfuscations or techniques are considered relatively weak, so one cannot use those. But the strong algorithms are actually the ones today usually need more processing power, which is not the cases one can see. As mentioned before, many of these also have brownfield kind of equipment out there, meaning they don't even have any thing to work with cryptographic testing. And one would need to sign transactions, sign messages, decrypt data, encrypt data. So the challenge become, I would say, becomes more apparent. Now IoT blockchain use cases, quite new for the last five years and becoming more and more apparent in the market. I didn't put here any market slides as far as what the market is adopting. But interestingly, Gardner has found that there's an 80% growth to CAGR year over year of the IoT adoption rate. This is very interesting. It's very similar to the ones that we see in the digital assets area. One can imagine the fact that cars are being very much driving this industry even though a lot in the lab, but still cars and all the equipment's around that. So here you can see that there are two types of ecosystems. One is the centralized IoT system. And one can say this is not really an ecosystem of blockchain because it is centralized, but we'll see in a minute that it is in those private blockchains. The one that we tend to consider a real blockchain is the fully distributed one, meaning peer-to-peer, no central server. But what we see is the fact that you have these various types of blockchains. So of course, there's the centralized one, which is not a blockchain. This is a centralized database somewhere where we all know these are the typical organizations that we all work with. There's the decentralized and of course the distributed one. Today we're going to focus mostly on this one because this is what we see with the enterprise-grade of customers. Meaning they do need blockchains because they are creating ecosystems where they do work with customers with suppliers, with service providers, with partners and consumers. And therefore they need to be able to move data and approve transaction and authenticated devices between various types of them and certainly a lot of them. But it's not a fully peer-to-peer kind of ecosystem, but there is a central server somewhere, wherever it is. And still there's for several cloud servers that do create like a magnificent, mighty database blockchain enabled. So the data is shared in an anonymous manner between the various types of mini ecosystem. So let's see a few examples. So a smart home example, of course, all of us will have a smart home in a biome environment where we have inside many IoT devices. So it could be even the shades, the lights, of course. We talked about thermometers, air conditioner, et cetera, garage doors. So there's the ecosystem within the house of various types of IoT devices that have to communicate with each other. There should be, of course, an in-home server. One can imagine that these are different manufacturers, of course. And still the data must flow securely between the various types, regardless of the manufacturing, I would say, party. But you can also start imagining the different layers of ecosystem. So it could be in-house, in-building, in-compact. You can imagine like a Bosch, for example, as a manufacturer requiring data from all the longer machines in a certain location, in a certain complex, in a certain country. You can think of consumers exchanging data between them to get recommendation on specific long-term machine, et cetera. So the security challenges would involve provisioning authentication, protecting data address, data transit, and of course, transaction of data, proving data between various types of IoT devices. Or even turning on, turning off different devices, et cetera. Examples of what could go wrong, in this case, would be several opening doors. Safety-wise, one can imagine what could happen if it is at home and someone is able to privacy. You do not want to share the data with someone you have not approved sharing the data with. And even less, I would say frightening, but still concerning, is energy turned on and off. Let's say you come home and everything has been turned on. It may not be scary for the first time, but maybe for the third time it is. And certainly, a waste of energy. Any questions so far? Moving on. Another example, this is a smart city. This is a more complex example as far as what could go wrong. I think some of the examples within are probably outdated. They have their own use cases. Still the connectivity, parking, autonomous vehicles, pollution. There has been, even just a few months ago, I'm Israel, by the way, and there has been an attack, which no one really knows where it came from. One can only guess on the water supply of Israel. So someone messed up with the water supply coming in to most of the Israeli homes from, I would say, one lake or one source of water. And the amount of fluoride that was injected into the water had been, had the attack had been successful, would have been dangerous to consume. Simple drinking water. So this is not anymore like just saving energy, but could really be quite dangerous if one could know where to mess up with the data. You can think of train going out of function or going much faster than they should. So many, I would say, dangers that could be inflicted on various IoT devices. The ecosystem here is, again, very interesting, blockchain-wise. You can think of the various types of IoT devices. You can think of the areas that would collaborate on data. You can think of manufacturers all around the world trying to get data, let's say, from a specific type of truck, doing something, so many things to analyze, a whole different kind of use case, but analytics of this. But this is really interesting and starting to get momentum. And this is something that Unbound has been fortunate enough to take part in, without these goods and too much data. But this is a public slide of Toyota, which has its own blockchain lab and is building something really cool in the sense that they're building an ecosystem of manufacturers, service suppliers, dealers, retailers and consumers to be able to consume, share data and work in a blockchain environment with various parts of Toyota cars and Toyota services, even the entertainment system within Toyota cars. So they're building a really cool blockchain type of environment. And again, they have to address security challenges, such as the ones that are written here. I would say that the automotive car is a much more complex one compared to the smart home one. Whenever it comes to regulation, each car has several I would say ECUs, they call them mini servers within that have to be protected. And it takes about 10 years to be able to get something into each of these ECU units. So it is happening. It is moving slowly partly because of regulation. And I think we should all say thank you for them to move slowly in such a cautious manner because none of us would like to draw a card that has been taken over by, I would say, Hacker. So the current status quo as far as IoT blockchain security is, these are the various types. I was very much surprised to know that these are still the ones that are protecting most of the IoT devices. It is not surprising from where we started the conversation in the sense that many of them don't have secure elements or have very poor processing power. But it is interesting that many of these authentication tools and security tools are pretty much evolutionary wise, the ones that were popular 20 years ago. And not much advancement has been done since then. So what are the challenges with current authentication tools? Many of them, one can imagine, are platform dependent. Even though there are many more types of IoT devices compared to, let's say 20 years ago, they're manufactured by a huge array of vendors. Hi TCO, we had one customer with which we wanted to work two years ago. And interestingly, that customer said, you know, for me to be able to put it doesn't matter which key, whether it's MPC key share or a full key. On my old IoT devices, their spread all around that would cost me two million dollars because I have to get dedicated teams moving now all around the country to be able to implement those, whatever it is, on those very old IoT devices. So they were very much sorry to say they would not be implementing not MPC, but nothing else into taking, I would say, the risk that something would happen and managing that risk because they cannot afford to put any type of security means out there. So in their case, without disclosing their names, their name, they're simply managing the risk of something happening. And we all do that on a daily basis. You know, we're not protecting everything with the best, I would say, security means, but we manage the risk for that. Resources, constrained devices, we've just talked about these types. Many of them, actually most of them out there, whether these are weak devices or old devices. And of course, we just talked about the fact that they're not secure authentication rules. They're very much outdated, have been around for at least 20 years where most of the hackers are not even 20 years old for that matter. Any questions before we move on to MPC? OK. So going back to this specific slide, so if this is how MPC would work as far as creating a key in a split manner, sharing it between the various signers and using it in its distributed manner, now one can imagine the various use cases. So this is the smart home example, just in one case. We've talked about the smart home example and what could go wrong. But now can you imagine a situation where each of these devices has a key share? And the key share is the very, I would say, lean and mean type of data, a very small file, just keel byte size in the sense of sizing. And it could be put on whatever IoT device that you want to work with as long as it has even a mini server with some processing power. So you can now start imagining what you can do. It is important maybe to emphasize that the minimum authentication that would be required would require at least two key shares. So you would have one key share on the client side for that matter. The endpoint is an example, the door lock and one key share on the server side. Now, these could be more key shares, let's say five. But honestly, one would not, you know, if I want to open my home door, I wouldn't want now my, I don't know, life partner or kid to jointly sign such a transaction with me. I just want to open the door, right? So I would authenticate using probably multi-factor or at least two-factor authentication, let's say my fingerprint using a mobile device and using another key share that would be on the server side that would be able to open up the door. Same one can imagine, for example, turning on an air conditioner, etc. You know, the examples are very various. Now, the authentication could be done using two clients for that matter. One could be on the mobile device and one could be on a mobile device such as a phone. So the examples are various as far as what you can do with it. But the principle is pretty much the same. At least one key share on an endpoint, at least one key share on the server side. And as long as you have at least a pair of key shares, you can create this secure boundary as far as we can. Any questions? Open the door now. This is Jonathan. I'm just curious. So are you using SEC-P256K1 in Snore signatures? So are these separate private keys that you're doing like M of N? Or are these, like, how are you combining these split into shares into either a signal signature or validating the multi-signature in M of N? So thank you very much for this question. So it is in the direction, in the sense that there is an encrypted signature behind the scene. The various key shares actually decrypt the encrypted signature. So as soon as you reach an M of N decrypted or key material, you can able to release the encrypted or decrypt the encrypted signature. So it's not multi-signature in the sense though of full keys, but actually M of N exactly as you mentioned, where the M of N have to decrypt the encrypted signature. Okay. So there is a private key on the IoT device in order to un-encrypt the need of M of N from disperse other keys in order to, for that key on that device in order to afford the function. There is no full, there is no full private key. There is only a key share. The key share would be wrapped by an authentication key, which would be a full key, but this is just a full key to wrap the key share. But there is no full key as far as the decryption of the encrypted signature in order to, let's say, approve a transaction or sign a message. No full key. However, the phase of the communication is, whether it's a message, whether it's a transaction, there is no full key ever. Okay. So it's snore signatures? These could be snore signatures, yes. This could be EDDSA, ECDSA, snore. We're pretty much agnostic as to the type of signature that has to be created with crypto agile. This is one of the advantages, I think, of having it on a software meaning, you know, snore is new. I don't think it was two years ago. I'm not sure, but we support it now. So we don't know what will be out there in two years from now. Okay. Thanks. This is more challenging, I would say, for the IoT environment regardless of when down. The fact that this market is moving so fast, you know, you cannot replace IoT devices every two years out there. Okay. Tesla example, this is a real example, the vulnerability one, not the protection one. So two years ago, there was a relay attack where someone was able to steal a Tesla car model S. I'm pretty sure they've changed it from now. So I do apologize for the fact that I'm giving Tesla as an example still today, but it is a nice anecdote for that matter. And at least two years ago, they authenticated the transaction of opening a car using a key that was fully kept on the phone app. It was actually stored in the app's sandbox folder and therefore vulnerable to malware. I'm pretty sure they have changed it since then, but this was the situation then. I think this is another testimonial of why, when this is very, I would say, expensive type of asset and the car is of course such type of asset, one would not want to rely on a full key on the app of the end user. This is the case, by the way, with the self managed or self sovereign keys wherever identity is being discussed. Let's say with Hyperledger Indy just as an example. So this is very useful when you're speaking of, let's say exposing one's age when you're trying to get into a restaurant or a bar, but I wouldn't want to be able to open a car using a key that would be stored on my device in its full state, in its full entity state. But this was the case with the Tesla Model 5 or Model S case a few years ago. This is, I'll show you now an example of how this situation could have been addressed using MPC. Keys could have been split between the car owner and the server on the Tesla car. We just talked about a few minutes ago, the fact that each car today regardless of one bound has many ECUs within. So one could leverage one of those ECUs to be able to open up the car where one key share would be on one of those ECUs servers within the car and one would be on the mobile device of an end user and making sure that nothing can happen. Let's say if even the device was stolen or has been blown just as an example, one would have to use multi-factor authentication, let's say a fingerprint just as an example, but could be more than that even an OTP, et cetera to be able to reach a car or to open a car, sorry. So one can imagine just even convenience-wise regardless of the security thing, just reaching the car with my mobile phone and being able to open the car without moving around with a hardware token for that matter, which is the old-fashioned key that we still all use in one way or another. So this is a great example of how MPC could be leveraged to do that. Home door example, we talked about that. So the key could be split and shared between a mobile app and server side could be on the phone itself and the home lock door could have mini server on it. So this is already happening in few hotels worldwide. So this is very interesting as far as moving around but one can imagine an entire ecosystem blockchain-wise as far as creating, let's say complexes of vacations, hopefully we'll all start, sorry, there she goes, to open doors in complexes of vacation houses, et cetera. And going back to the Toyota example, this is becoming more interesting because now we don't talk anymore about one, it's a key that is not even there but it's still being shared between two parties as we've seen here. So you always have this pair with the Toyota case. We're actually starting to make use of the fact that the key could be distributed between N parties and you need M of N to be able to sign a transaction. So one can imagine at Toyota, let's say consumer, a buyer going into one of their dealer houses, wanting to buy whatever it is they want to the car and you have the supplier, you have a customer and a dealer on the other side, you want Toyota to be aware of this information without disclosing the, let's say, even the private details of the consumers themselves and one can imagine the various advantages of such a blockchain type of scenario, you can manage better the supply chain, you can manage the amount of equipment that you have moving around the world in different ports and different manufacturing houses, so much more efficiency, so much on demand, I would say, supply to the specific point of supply to the end consumers. We have such an example with Walmart even though it's not an IoT use case but I think it's a very interesting one because Walmart now buys vegetable and all types of fresh produce from their local retailers just on the type of supply requirements or demand requirements, I would say, so they don't need to keep tons of tomatoes just as an example in warehouses, getting them less fresh day after day because they can get messages from the local supermarkets using blockchain to be able to address demand in a much more faster manner than before. So with Toyota cars and equipment, this is not, I would say, as sensitive as keeping tomatoes as fresh as possible but one can imagine that the Toyota-related supplies or IoT devices are much more expensive and therefore they do want to make it much more efficient. So this is another example. Any questions before we dive into the threat model or maybe we should stop here for discussion? Yeah, Jim, may I ask one quick question? One of the challenges I've worked on Moby Standards which is for the Mobility Open Blockchain Initiative on vehicles which includes Tesla, Toyota, and all the other stuff and in there we were looking at security and keys with the challenges of trying to talk about, everybody talks about hardware wallets and so on on the vehicles. The bigger challenge for me has always been I'll go with the practical real-world ability to recover keys and access when they're corrupted, destroyed, stolen, whatever, compromised. And I don't see anybody really addressing that well and having experienced, you know, to your point about autonomous vehicles, one of the good reasons they're going slow is that many of the scenarios that do exist in the real world are not yet addressed in AB driving scenarios for sure. The same problem applies to, in a sense, any identity access solution for sure and I assume there's no difference with multi-party computation key management as well. You still say, okay, if you have, in a sense, this multi-party key like you showed in the example for the car you say, okay, your phone is now destroyed or the ECU on the car has been destroyed, which is very easy to happen. You know, can you still, in a sense, access the vehicle? And the answer is probably not. And what's the time to recovery? So if you think about recovery models, we talked about RTO and RPO, recovery point recovery time objectives. And I don't see any of that kind of stuff specified or, in a sense, these types of solutions, which maybe in many cases is not critical, but in certain ones like vehicle access and so on, it would be critical for sure. Yes, thank you very much for this question because very fortunate Unbound MPC is addressing those issues with the fact that these key shares are being refreshed constantly and one can suspend or even revoke a key share to be able to generate and enroll another key share, let's say, to another party. So just as an example, if one, actually it is shown in this threat model that I'll show you in a minute. Let's say someone loses their phone or their phone is being stolen. So you can suspend or revoke that key share. You can enroll another key share. Let's say if you bought a new phone and you want. So yes, so it is addressed. But if it would be helpful, if you took like exactly the car access scenario and said, okay, walk it through a recovery model, which says, okay, the phone is to your point stolen. So I don't have a phone. What is the recovery time objective that we achieve that we're going for, I should say, in that scenario? Is it minutes, hours, days? What is the actual recovery time that you're talking about? So let me address the general scenario. General scenario, it's a matter of seconds. We've done so. Even yesterday we had someone in another, I would say customer, not a car. I would say we're not working yet with cars. As I've mentioned, the automotive car is moving so. And I think we should all be thankful for that. But another customer, even yesterday, a real life example, someone bought a new phone, wanted to upgrade the app that we're using with them, something went wrong. And it was just a matter of seconds before we simply revoked the old phone and enrolled the new phone with the new key share. As simple as that. So this is a very, I would say, easy example with that specific case. This was a digital asset type of management system. So the time frame is very critical. You cannot have any compromised key share whenever you're trading or safeguarding a million dollars, like even much more expensive, you know, than a Tesla car for that matter. I think that the more concerns when speaking of automotive are actually not so much, you know, stealing the mobile phone, but taking over a car, something like that. So I don't know how far the industry is there as far as taking over an ECU, et cetera. Yeah. If we could dive into the threat model, I think you'll find some examples you may find valuing. So these are just a few. I'm not covering all those, you know, I showed you in one of the earlier slides, about 30 types of attacks. So these are the main ones as far as just, you know, for our discussion today. So it could be mobile traffic, the redirection and network adversary, of course, very relevant where you're talking about, let's say traffic jams, traffic lights being messed around denial of service, of course, side channel attacks and device cloning, which would be the case. Let's say with someone taking over someone's mobile phone in order to open a car if we address this specific example using this specific threat. So when focusing on the network adversary or traffic redirection using MPCN, and here I do have to go back in the sense of do taking, I would say, pride in the fact that I'm part of unbound. This is not generic MPC protocols that we're talking about, but actually unbound solution for these types of challenges. So with unbound solution, all messages are encrypted. There's a unique counter to prevent replay attacks. An attacker cannot learn anything about the message from the mobile phone. If you remember these are key shares, these are simply data file messages, nothing really that can be... This is not cryptographic information in the sense that one can steal it and you use it in order to do something. They have to break into all mobile devices and all servers. If you remember that Toyota examples with at least five key shares. So one would have to break into all five devices and additional servers at the same second because everything is being encrypted and all the key shares are being refreshed after each operation and after intervals of time. So even in the unlikely event of a device being compromised, nothing can be learned about other devices at the same time. This is to emphasize that the shares are random between the various parties. It is not just as an example. If the entire key is 100, this is an example. And these are five copies. It's not that every party gets 20, 20, 20. The shares are random. They're being split in a random manner. And after each refresh, every party gets a different random share. So this is to address this type of a diversity attack. Device cloning, which would be, I would say, more relevant for the car example. So when humans authenticate, it will require multi-factor authentication with devices that have secure elements such as iOS. We are using the iOS secure element to be able to store the key share itself and the authentication key, of course, that traps that key share. The key shares are being refreshed continuously. And if a clone device did carry out an authentication action before the legitimate device, the MPC solution protocols will detect the clone attack and raise a flag. I would like to emphasize here, which is not written down, that unbound can very easily, and we don't have time today to show you an actual demo, can suspend and revoke a device in a matter of seconds once we order the customer for traces and issue and be able to re-enroll another device or the same device if it has been just suspended in a matter of seconds as well. Backup-wise, this is something that is not mentioned here, but worth mentioning in light of the former discussion. Thank you again for the question. Backup is also MPC-enabled, meaning the backup is being done using key shares or two full keys, by the way, RSA keys that could be or should be used together in order to recover assets for that matter, or data assets. And this is also a unique capability of unbound, the fact that it's MPC-based, publicly verifiable, and could be used by the organization itself or even a third party. Whether these are, you know, just as an example with the Toyota example, they could use a third-party consulting company to escape in G or Accenture to be able to backup the information as a trusted escrow service. Side-channel attacks, as we all know them, take advantage of the fact that the same keys being used on the same machine, same processing chips and information such as timing, power consumption, electromagnetic even leaks or even some could be used to create side-channel attacks. So with the case of unbound MPC, the fact that these are random shares on the server side and the endpoint side mean that there is no full key to be able to steal or to attack. And again, that sharing refresh takes place every operation, every interval of time. And I think that the last attack that we may want to talk about today is denial of service. So usually the denial of service rely on the fact that there is some kind of a proof of work that the IoT device has to do upon enrollment. But with MPC, as we've mentioned, this is the breakthrough. It is done so fast as opposed to, let's say, any type of other operation or suddenly MPC, let's say, 10 years ago. So the verification would be so much faster than the proof of work that would be required in order to create the denial of service. This is unrelated to the fact that usually you'd create high availability type of environment, server side, using different clouds at the same time, creating some sort of redundancy between servers, etc. Automative industry, a whole different kind of story. You cannot create ECUs or multiple ECUs for each function in the car. So much more complicated, a real challenge. And I am actually very much envious and admiring all the automated people that are working diligently today on these scenarios. So this is just to summarize MPC. I think you've got the hang of it as far as what's behind it, what it can do, the use cases it could be used for. And that's it as far as I am concerned. Thank you so much for your time. I have a couple of questions. I think we have a couple of questions. Yes, thank you. I have a couple of questions. Obviously you're talking about some kind of a ratchet protocol or something that refreshes the keys. So that would assume connectivity, right? I mean, without connectivity, that refresh cannot happen. Exactly, yes, you are absolutely right. Online connection is required for the refresh, yes. So coming back to the question of, let us say, use of IoT and blockchain, one of the more interesting ones is where you track the provenance or even the progress of material and also the temperature or the pressure. Like for example, you can have an IoT device inside a container that brings some sensitive material, but often this is at sea and it is very difficult to maintain connectivity throughout. So obviously there has to be some kind of protocol to secure those IoT devices and to be sure that whatever they're sending back is good data that they cannot be sabotaged. Yes, absolutely. You are absolutely right. When these are offline servers or endpoints, the refresh becomes a challenge. I would say that it's much better than having no, I would say empty sea around because I would say the worst case is actually having a full key that is not being refreshed ever. So it is an advancement, but yes, connectivity would be preferred in order to allow for that refresh to happen. I would like to address a workaround around that that we are doing with various types of customers of us. Whenever one of the devices would be offline, we do recommend having a policy, we call it, of at least a few devices that would have to take part in a transaction, some sort of a transaction. We are leveraging trusted systems where some of them are fully cold, therefore not refreshing key shares and some are hot, and both sides, both systems are required in order to sign a transaction, let's say the cold one and the hot one. This is a much more, I would say, sophisticated use case. I don't see it really happening for IoT devices unless these are very, very, I would say dangerous ones. Let's say trains just as an example, but it is possible if one would really want to do so. And what exactly is your product? Do you sell the libraries or do you sell the full solution? The full solution. Okay, because I had heard that you also allow people to build something on top of the libraries you provide. Yes, actually, in the sense of, we do have an MPC library, two-party MPC library open-sourced. It's in Git. It can be found very easily. We've spread it around actually as a means to educate, I would say, even the market when we started out five or six years ago, people were not very much aware of what MPC is or what it can do. So we simply released the two-party MPC out there. So these are libraries that anyone can leverage. We support whoever wants to use them. I wouldn't call it a solution. These are simply very low-level type of MPC two-party. But you also have another library that is multi-party, that is licensible, right? Yes, yes. But not, I mean, I'm not talking about a full solution. Just that and then you build on top of it to, I mean, I think it would be useful to talk very little bit on the difference between, let us say, multi-sig, which many people implement and MPC, because that is a striking difference. Yes, I don't know if, sorry, if we have the time, I do have a great slide specifically for that. If we can just spare two more minutes, I'll find that slide, open it up. And I could show you in just one slide, the difference between multi-sig and MPC. Let me just find it. Or we can, you know, continue the, it's okay, it's good. You can show it, you know, we can extend by one or two minutes. Yes. Of course, we will remind you that we are also going to have the presentation of this in, of something similar in the capital markets thing because we are talking about high value, you know, transactions. Go ahead. Yes. So this is just one slide and I'll finish with that. So thank you for the question. MPC, we consider it next gen multi-sig because everyone knows full key type of old fashioned kind of security means. This is what HSMs do very strong for protecting keys. Challenges that would block chain just safeguarding the key itself is not good enough because one doesn't have to steal the key. They simply have to see the key in order to steal the assets. So this is pretty much why multi-sig has evolved. So there are multi-pile keys that each and every endpoint or signer is holding. Actually being required to sign it and being accountable for that on chain. The cost of that is the fact that it does not support all ledgers. We just talked about Schnorr. I don't think I'm not sure if Schnorr is supporting multi-sig. We do know that there are many ledgers that do not support multi-sig. For example, the point of stake type of assets, you have very limited quorum structures that you can create up to two out of three. And if you want to create more than two of three, you have to code very sophisticated scripts into that. And there you go into application security type of rules and spark contracts, which are very vulnerable on their own. It's hard to change approvers. You have to decode them out code additional signers in unlike the unbound solution where you simply suspend or revoke and enroll a new type of signer. And of course, if you're dealing with heavily operation cost-oriented type of organizations, the fact that you have more and more signers on the same transaction, meaning you're paying higher fees. With multi-party computation, none of this happens. Specifically with the unbound solution, which is multi-party as opposed to two-party. Everything is cryptographically still validated. You have distributed policy enforcement. This is really important. This is not one server validating the policy, but each and every one of the signers is validating the policy. Any ledger could be supported. No limitation as to the quorum size. We've been talking today a few times about five signers, but we have examples with ten signers, each of them holding just a key share. Approvers could be updated very easily. You could have offline approvers as we've talked about. And you could have optional hardware integration. So all of this is pretty much why Gartner is saying that MPC is the next-gen security infrastructure. Yeah. The main difference being that the sign takes place outside the ledger. Yes. In the multi-sig case, the signing has to be authenticated by the smart contracts, which can get pretty complicated. The complication in this MPC case is outside the ledger. So anyway, it's a very fascinating presentation by Rebecca. Thank you so much for showing up. And I hope you can share at least parts of these slides with us so that we can put them on the site. Obviously, it will have all your, you know, your marks on it. We are not going to alter anything. So that's that. And I'll put up the video of your presentation that you have already recorded in the audio as well. And you can use that for other purposes as well. So that's all for today. But Rebecca will come back for the capital markets next week. And we can talk about some of the high value institutional type custody, and the other types of custody, but basically it's a slightly different use case, but using IoT devices. Thank you. Thank you so much for everyone for taking the time to join. I know it's not, you know, obvious. So good morning, good evening, everyone. Hopefully we'll meet again next week. Bye-bye. Bye, thank you.