Awesome. Yeah, thank you, Houchy. And we do have a number of great blogs that our engineering team has written up on wallet security, different aspects from from ranking security as well as some wallet fishing campaigns that we've uncovered. So yeah, well, it's really are a big target in the web space for for
So that's why I was so happy to see Zengo take a really proactive approach to mitigating this vulnerability. So maybe tell you can just give an overview of Zengo. What is the approach that you use the multi-party computation approach?
That's the Q is your wallets and yeah, just given overview of your service. Oh, that's great. So like I think there was an old Nokia dish that says so radical today. So obvious tomorrow. So I think this is the same for a NPC right now because
When we started four years ago, it was like we had to expand again and again what is MPC and today it's like MPC of course, it's the way to go. So MPC really solves the fundamental issue of which is in the heart of many security
in the cryptocurrency world and this is the problem of the private key vulnerability. Having one monolithic centralized public key that you have to put it somewhere, it can be either you take it as a user
under your responsibility or you just give it away to another service and every option you take as pros and cons if you give it to a service, then the service can get hacked. If you give it to yourself, you can get hacked or lose it, etc. So it's very hard to manage for a
for users, for other than users that don't want to be their own bank and certainly don't want to be their own security officer. And that's where MPC comes and really solve that issue, core issue of private key vulnerability by distributing the security
and the key in two multiple parties, in the case of Zengo, one part of the secret is saved on the device, the personal share of the user, and the other one is generated on Zengo server, and only together they can
really signed the transaction for the user. And this is a great technology because it's core chain. It's not specific to Bitcoin, to Ethereum. It works in the mathematical level. And really solve that core issue of that private
key vulnerability on top of that you can have a reliable recovery service and also protection against theft because now attacker and we will touch that I guess with the aesthetic findings needs to hack in theory both Zengo
like the user device and also hack Zango server because it needs both parts of the secret in order to actually exploit and send production on behalf of the user compared to traditional wallet in which you need to
compromise just one party either the server or the client. Using that technology it's an able to build a highly usable yet secure wallet that occurs also other parts of security. This is for Nettock but also it solves all kinds of
of Web 3 problems and so on and so forth. But the core technology and what makes Zango special is the MPC and also other security mechanism that we would probably touch in this talk. So sure. So it's the multi-party computation that allows for securely having
Basically more than one key securing an account which is so important because we've all heard stories of people losing the one key to their Bitcoin wallet that now contains a fortune and Bitcoin that they can't find. It's a huge responsibility to be your own bank. You really have to take on a whole lot of security.
which some people are fine with, but not everybody has the interest or the technological sort of sophistication to be able to do this. So that's where Zengo comes in with the splitting up the key, a much more usable, secure solution, as you said. So let's get into this actual, the vulnerability.
Maybe how you could discuss how you came across this, the background research that you've been doing, your team of engineers at the Skyfall team in general. Right, yeah, for sure. So as we were mentioning that our team, Skyco team, as CERDIC, we care a lot about how weather was it.
secure or not, right? Because everyone is trying to have a fortune in their process. And we want to know that whether this type of wallet application is secure enough to protect their users as well. So we look into them and as we mentioned in there are several different types of ways that wallets are protecting users.
They are trying to, you know, encrypt the private key and store them locally and some of them are trying to do this kind of like a transaction and trusted execution environment as last time we were talking about and then we came across the NPC as you were mentioning, you know, right now it's trying to eliminate the possible data
of single point of failure. You don't really have a single key anymore. If one of your keys compromised still doesn't matter because you have a server side or any other part side to collaborate together to approve for one transaction. We look into NPCs
solution and we find out Zingo is probably the most popular wallet, MPC based wallet solution, which is available for individuals. Say yes, there are other MPC solutions on the market right now, but most of them are like designed for like enterprise or business sites. So for
Individuals, I believe, they go is probably the most popular one where you can just simply download it, you can use just simply just to sign up and a user while. So we kind of want you looking to, okay, right now, given their popularity and given their, they are using all sorts of techniques to protect the user. As a, that's looking to how, how
So how great they are doing this kind of work. And so we collected some kind of background knowledge how to implement their NPC, how to implement their server and kind communication. We took a lot of effort on reverse engineer their protocols and also thankfully they have a lot of
open source on their website, on their GitHub, so we can look into, we can kind of cross-exam the code that released is actually the one that being using inter-applications. So we take all their security design into our consideration. We took a lot of effort on reverse engineer, the communication
protocols and then we finally came across one because Zingo, based on what we've been doing, and also like the details we have been putting in the blog. So Zingo had done a lot of great things to protect their users as more than NPC, which I believe Tau can introduce them later, such as, you know, like they have
their facial recognition, their magical link, their mechanisms, their all sorts of stuff, you know, try to protect users more than just MPC. So we took everything, we took a look at everything they did and we came across one API which is not that appropriately protected and we
kind of like a came up with certain case where we think, okay, if your device is compromised, then maybe the attacker say like they're using say you have the root device or like the mailware that has been implanted on your device may have some kind of advanced techniques which can obtain
a higher privilege or anything like that, so which eventually lead to uncertain cases that a attacker may be able to compromise your NPC protected wallet in our case, unfortunately, then goes wallet and they may be able to steal the phone. But again, this kind of case are kind of rare.
But I'm glad that then go also take this kind of like a rare case into their considerations and correctly implement the mitigations to protect the further protects the users. I believe tell tell you can introduce a little bit more on the security mechanism that you guys implemented to protect users.
So thank you for the balance in production and let's remind ourselves that you know it's only due to the NPC nature of Zango that protecting against infected device, device infected
with Miller is even a question because when you have a certain you know classical wallet and I think Celtic has done a great job in reviewing some of them a few months ago that it doesn't even start because you know like when
the key is stored on some part of the device and if the attacker is able to install a malware then they win it's the game over for them. So only with the NPC like there is even a chance
for this to be an issue. So we need to take it into context and this is a second for framing it the right way. This is relatively rare and also like to form the practical empirically we've been around since two
2018, nearly a million users and none of them was hacked. And this is also due to other security mechanisms we built on top of the MPC. So how do you already mentioned the magic clings? So it was very important for us that we don't substitute the seed freight vulnerability with
another vulnerability of a password. So there are no passwords in Zango that you can be fished or you can be lost and don't remember. So everything is things you have. So in order for the user to log in into their account or recover, let's say
recover their account, let's assume that the user has lost their key, lost their app or device, then one element is the email address of the user, so we're setting a magic link to that, others to make sure
that indeed the user has a position of that of the of its inbox. We have we're on set up. We take a server side, a biometric face scan of the user, provided by a self-party vendor, by
FACETECH, Zoom technology that is being used by multiple banks and other trusted companies. And this allows us to have a reliable service side byometrics identification. And we also set an
And this is one of the core elements of the discovery certificate made. We are also enrolling the device by leveraging the hardware, secure trusted execution environment, the T or secure and clever in
in iOS to create a hardware protected and a private key for the user. This is another private key. It's not related to the blockchain private key, but the
good part of it is that it's maintained in the hardware. There is no way to get it out of that hardware. You can only get cryptographical services from that hardware. We use that in order to sign...
on setup the user enrolls its device with this key that is created on the hardware and enrolls the public key of that key pair and later on it signs every important request
to the server specifically for sending funds to the blockchain, to another address, it needs to be signed with this hardware protected private key, which means that why we created that, that we had that
case of malware in mind and said, look, this mechanism is binding the user to its device. So if a privileged attacker is able to just copy everything in memory and try to
send fans using their clone device, they will be missing the how the device key, which is stored in hardware and would fail. How did I miss anything important in the description?
I think it's completely clear that how you guys are doing through the actual steps that you guys are down to protect the users instead of just simply leveraging NPC. I think that's what you describe. I think that's right.
Let's talk a little bit about these trusted execution environments. I think they are very important for the future of mobile wallets, especially. Obviously hardware wallets like Ledger and Trezo, use very similar secure enclave. But a lot of mobile phones these days are included
So this is an interesting question because it cannot be used directly for several reasons. You could say, OK, why don't we make the mobile device your hardware device? Why do I need to carry
with me, you know, another hardware device with a very small screen when I have a big screen and I already have it. It's already in my pocket. And by the way, I don't think you need a hardware wallet, you need a secure mobile wallet, but that's another
But the security and claim of trusted execution environment cannot be used directly for two main reasons. One is a bit tactical because the curve that is supported on that, how do we divide it?
not compatible to the curve that is used on blockchain. When I say curve, it's because the encryption is an elliptic curve. This is the parameters. There was four historical reasons. NIST.
The American Institute for cryptography and standardized another curve and not the curve that's used by blockchain. And because I think originally blockchain didn't want to use that curve because they thought the NSA may have played with the parameters.
But in the end of the day, you cannot sign directly, let's say Bitcoin transaction from that security and clever T that is already present in your modern mobile device. So this one thing, maybe it can
the future. There's one more strategic problem is that we said that the key can never leave your hardware which is great against theft but very bad for availability. So if that device dies then the secret dies
we did along with your funds. So this is a really big problem. And so like the way to leverage that hardware is to have it as a system, as we do it, it helps to what we use in
It helps us to bind the user to the device. So even a clone device cannot be used with this user ID and secrets. There might be other ideas how to leverage that. We'll very open to that.
There are some emerging technologies that are really niche and specific to certain blockchains. For example, a counter-abstruction may enable us to, in the future, to solve both the problem of the different curves as it
separates the signal to curve from the blockchain, the capital Z and also the key from the account so you can also switch keys and maintain the same account. But generally, you cannot use this device.
directly to a wallet only to do some kind of security enhancement to your software-based wallet. That's my view on that. That makes a lot of sense and I can see how that fits into the Zeng
approach with multiple multi-party computation and splitting the keys into multiple parts for accessibility and security. How she once see you and your team came across this vulnerability, what was the process from there? I'm assuming you wanted to verify that it really was what you thought it was and then you wanted to get in touch
with the Zengar team to mitigate it. Could you just walk us through that part of the process? Yes, of course. That is a really important process for secure research, because we want to be responsible to disclose what was happening and especially to venture. So, when we can work across, again, at the very beginning, we want to know that
that, whether then go, then goes design secure or not. So when you go through their design, it feels like, okay, there's two, one, two, three, four, all these types of different steps to protect the users. And then, you know, like, so, so most of them are correctly implemented. But as we were mentioning, we still found one place is not
Now that's appropriately implemented. So when we came across that, the first thing that we do is conducted a thorough experiments to evaluate this type of like a misimplementation and see if it's actually what we saw. So in our case, we kind of like it just set up a few
test account and set up a few tests in our control environment. And we wrote certain exploitations, we wrote certain payload, and we looked into how this type of vulnerability
more security issues can be exploited, just assuming that we are a group of attackers, you know, because they have ability to control your phone, they have ability to escalate to zero privileges and anything like that, which kind of mimicking a legitimate attacker. So when we confirm that this
This is actually a thing and we think there might be some misimplementation going on on the server side. So we immediately contact Zingo and we talk with that, we talk with Tao and we share them all the details on what was going on and we think there might be something wrong over here and we just want to be, you know,
As parents, we want to be straightforward with them and providing them all the details that we have. And the gladly tell was also taking this type of security risks very seriously. So we scheduled the follow-up meeting and we talked in detail about what is the root cause of these kind of security issues.
and what could be the potential impact, what it can be the potential mitigation. So then tell their team spend time on their side to verify if this is true and to implement their mitigations and to patch them. So when, of course, when they down the soil test on their side, because you know,
When you patch stuff, you don't simply just patch it because you do want to make sure the functionality of your products is totally fine. So when they are done with everything, it took a couple of days and so they come back to us and told us, "Okay, this is the implementation. This is the mitigation that we deployed on our servers
and go ahead and try to do it one more time and see if it's correctly patched. So the skygoat team, we're looking to this stuff one more time, we go through all the mitigations they deployed and we confirm that this is totally okay, so then we come up a solution. Okay, then every
So we want to be transparent. We want to let the community know that what was wrong and why that went wrong and what is the step, what is the mitigation that we have deployed to protect the users. So we come up with blocks, we come up with explanations on what was going on and then go has been very transparent.
And very prominent follow up with this kind of question with this issue. So I'm to say I gladly like the sky go team and ascertained can does and go team like we work you know together. We're closely to first we identify the issue we verify if the issue is correct or not and then we talk with the single and
And you know, like in detail about what's going on and we add another way to be transparent about telling the community. This is the details and also we want to let other security researchers know, okay, this is the details and if you want to follow up, go ahead because we have everything that is available to us and then we make everything available to everyone.
So back to you Jesse. Yeah, that's great. I think that the transparency there is really important. And obviously these are these are very complex applications using cryptography using multiple different, you know, cryptographic and blockchain technology. And you can expect to have some some issues encountered the prop what matters is
Solving those as soon as they come up and I think Zen goes down a great job with that. Tal, could you just speak to that mitigation the identification and mitigation process from your end? Sure, sure. So first of all, I want to complement algae and the whole 30 skyfall team for real
it was very clear from the get go that we're dealing with professional. This was not only judging by the quality of the research and the quality of information how they presented it, but also they were highly professional in
you know in explaining and being really focused on solving the issue and not trying to be sensational about that and we sent them a lot for that that helped a lot and as they
how she said the issue was not a bad design. In fact, by design, we were planning, like we were aiming to solve that issue. It was a matter of a problem in the implementation that tried
to make sure that indeed all the criteria for registering a new device are met. An attacker could bypass, we try to make sure that the attacker,
that the user that are doing recovery and hence needs to register a new device actually went throughout the whole process including the phase authentication. However, the first attacker got it by pass that and what would
We did on our service side was to really enforce that face scan to make sure it really happened for the user that is going to the device and that really shut down the attack. As mentioned, this is a service side.
mitigation, therefore, users are patched, you know, in out of the box, many of them don't need to do anything, like you don't need to, as a user, you don't need to upgrade to a new version, you are
already protected because it was a server side fix and also like this what enabled us to deploy so fast also because it was like if we let's say we didn't even consider that
option of a privileged attacker then it would be very hard for us. We would have to introduce that hardware mechanism and so on and server and so on. So it was more of implementation error that we fixed and we thank Celtic for highlighting this
for us. And also generally we think like, you know, it's not great to have an issue, but you know, if you're building something meaningful, this is inevitable. So what you can do as a product that security matters to it. So
first, you know, walking security at depth, level kind of security mechanism that can mitigate some of the risks. And then also like walk closely with researchers or whoever finds that that issue
issue and quickly patch in timely manner. So this is the important thing. So you know, it would be great to have a product with zero issues, but this is of course not realistic. And it's really important that once such issue is identified that
And the team behind this product is able to quickly patch it in a clean manner. For sure, yeah, once it's been identified what really matters is getting it fixed and then a space like this, the blog post that we put out, Greg Ways to raise awareness of the kinds
of issues that you can expect to encounter when building critical applications like this. And yeah, I think it's a really good to explain the process and just raise the level of education in the space when building this kind of infrastructure. So yeah, I mean, it's been great to have you on
Al and Zengo. Keep doing the great work that you're doing. I think this really speaks to the serious approach to security that you take. And that's really for the benefit of all your users. And how cheap I think your team has been doing great work. Personally, I'm very glad that we can put out this kind of pro
active security research work with major players in the web3 space to make them even more secure. I think we can all agree that security is a major not hurdle. It's a challenge. It's a challenge that the industry needs to confront and overcome in order to give people the sense of trust and
transparency that they need to keep using Websterity to keep building. So yeah, it's been great to have you guys on. Thank you, Tal. Thank you, Hao Chi. And we look forward to working together in the future and Hao Chi also to seeing what your team puts out. I'll let you guys just sign off each briefly. All right. Thank you. Thank you, Jesse, for having us all right here today. Thank you so much.
Same here, it was a plan. All right. Thank you. Thank you everybody. What photos to speak in G next time? Yes, but