 Please welcome Marco Ben-Kuhn. Thanks Michael. Hi Ron. I'm Marco. I work at Shift Crypto. We're based out of Switzerland and we're producing hardware wallets out of Bitbox. Today I want to talk about security issues in crypto software wallets and more so from the perspective of software devs that want to write a wallet or maybe want to integrate with wallets. More so than this than from a user perspective where I'm sure you all already know how to secure cryptocurrencies. I also am going to mention a couple of issues that are probably obvious to many of you but still I don't want to talk about the standard stuff like which data type do you use to represent Satoshi and so on. I want to talk about stuff that I see in current wallets that are not addressed properly. I want to kick this up with a small history lesson. So a couple years back there was an issue in an Android wallet and a couple guys posted on Bitcoin Talk with the same issue. They had an address, they sent some coins to it and immediately the coins were stolen. And a very suspicious thing, the address had previous activity before they made it. So it's a classic so the guy already suspected correctly, suspected correctly that it's about a bad random number generator and it was completely right. So I want to go in and dissect the bug in detail. Roughly 235 people have been affected for the 5 Bitcoin lost by this bug. So this is the function that used to create the secret key that is used to create the public key that is used to create the receiving address, right? So fairly standard stuff. There's a secure random class from Java. They replace the standard provider with their own that streams data from slash def slash u random. And then there's this extra seed that they mix in. And here the set seed looks like it would replace the original seed but it doesn't. They make sure to override the function and actually mix the entropy. So everything looks good. So what is this extra seed? We wonder. So this is the function that is called to set the extra seed. It's called seed from random org. And it's the random org generator that they implemented. And this streams random data from random.org. Public service to give you random data. So you might think that's a little strange. Do I really trust some sites to give me random data? Probably not. But in the end, if you actually properly mix it with XORing, then everything should be all right. You can, in the worst case, just have the same entropy as before. But more doesn't hurt really. Okay. Also small race condition I can spot here. There's a thread running to set the extra seed. But here the seed is set at some other point in time. You know, who knows if the seed is actually fetched in time with the extra seed. So let's look at the code that gets the random data from that URL. So I want to go through this like code review style, like if you were in the company and I review your request. So I started at the top and I see HTTP. Okay, that sounds a little bit right. Why isn't it HTTPS? You know, there could be a line in the middle, et cetera, et cetera. Right? So then, you know, connection is made, get request, I'll find some connection timeouts. And then there's this line which says that if random.org would to respond with, you know, redirect response, then this should be ignored and we should just get the data from there. At least I would just question the offer if, you know, there must be a reason he put it there. Maybe he thought it was some way, maybe if you check the result or something, but I don't see any of this here. And in fact, random.org did redirect to the HTTPS version. They started enforcing that. And this is the response that they gave. So because the redirect error was, the redirect code was ignored, this was what they got. And then also suspicious, you know, in the end, you would hope to check for a 200 okay response. Or if not that, you would maybe if you get data from a untrusted source, you would check that the output is what you think it is. For example, we have the length up there and it's the length here, but we don't actually check if the output is the correct length. So what happens is in the end, bad luck, the random data from random.org is just those bytes, more than 32, but it doesn't work. So constant. But going back to the set seat, you know you think, okay well, so that data didn't help, but it also didn't hurt because set seat as I said before is XORing the data, so all is cool, right? What's the worst that could happen? Well, this is the function they used to set the provider data, like their own implementation to overwrite the standard implementation of secure random. And you can see it gets the data from your dash dash dash u random, all is good and it's set up here. But if the file does not exist, then u random is set to null and there is no exception thrown. So the implementation falls back to the standard one from Android. And that one doesn't XOR the data, it just overrides it. So there we have it. So the public key that they generated randomly ended up being a constant from random.org. It doesn't help that the random secure provider by Android in some versions also has severe bugs where the entropy is not 128 bits, it's just 31 because they just zero some black bits. And you know what are the take-aways from this? You know we all get it, you're a startup, you have, you know, products to market and the opportunity cost to write unit tests is high and to do lots of core reviews is high. And I think it's forgivable if you don't have full coverage on like in areas where bugs are at most an annoyance but if it touches your balance or your crypto keys or crypto in general, like if you should have reviews and functional tests. And I think at least one review would have got at least one of the five issues before which I would have prevented this outcome. The other take-away is if you fail, fail loudly, for example if dash, um, dash u random is not available, you should just abort an exception and not think, you can rely on something else. And the third and the most difficult part is to test your assumptions. Like in this part they assume that the, um, the random source is available on all platforms but it turned out not to be the case. And it's a hard part because often times you really don't know what your assumptions are. Like it, for me it helps to just take a step back and consciously figure out what am I assuming if I write this code. Like recently I had to port over some users from Bit by Wallet service to our wallet and I assumed their gap limit was 20. In fact it was unlimited for all versions so you know, it's easy to just assume stuff even if you write the code but it's, it's good to double check those things. Next I want to do a quick note on address placing malware. Of course we all know them, there's malware out there that, you know, hijacks your clipboard and replaces your receiving addresses or just browser extensions or Tor proxy stuff of the same. And one funny instance of that was when the ransomware locker instructed their victims to pay their ransom to them via Tor proxy and the Tor proxy decided in turn to replace the address. So the Tor proxy was stealing from both the victims and the ransomware offer and they complained about that as well. It's like, I heard. And there's a couple of ways you could deal with this and we are not there yet. I think in the end we will have a world where people are not copy pasting addresses of course. And there are various avenues to deal with this. One I'm interested personally is in a kind of a standard where hardware wallets can be plugged in into any service and you can just transmit your keys in a secure way without any copy pasting. So one area that also interests me is memory errors. I've looked at various wallet implementations and I don't see many actually giving this the proper attention that it deserves. You know, bitflips coming from cosmic rays or etc are way too improbable to actually hit your private key or whatever but old memory units that start to fail or degrade in bad ways they can actually make your life bad. Where does this manifest? If you generate the public key, you know you multiply your private key by the generator then you have a public key. If you have a bitflip or an error in the memory there then send funds to it, it's lost. Or what if you derive public keys from an XPUB also if you don't double check the result you could actually have a mistake in the hashing that is involved and also get an error. Also backups of course if you make a backup you should check that it produces the right private keys. And well this is Bitcoin core implementation. It generates a public key and it immediately checks that the public key is valid by signing something. I think they could probably go a step further and also check it before making use of it. Yeah if you have any hashing involved like keyboard key, password stretching, derivations then it doesn't hurt to do it twice in different memory locations just to reduce the likelihood. And then most wallet software also just keeps the data in memory without any check systems or error correcting codes which could be an issue. Yeah, actually if you store a public key you're better off just storing the address instead if the only thing we're going to do is receive money on it. Except you're in Ethereum land where you know checks are for buses. Next topic is pretty trivial and I'm kind of embarrassed to even speak about it but I feel I have to because I've seen so many local web servers running without any authentication. And you might be you know a guy that wants to someday try to make a local web service that's Bitcoin, RPC or Lightning clients whatever and you think because you're local it doesn't matter because I'm the only user I connect to it and no one else so I don't need any authentication. But you know most people are not aware that browsers can access local host and I don't mean like local host if you type in local host in the URL I mean every website can do this. Small exchange here, one guy also like I was in his shoes a couple years ago I thought this was ridiculous but to be honest I'm unsure why browsers even allow this. Anyway case in point there was an issue in Electrum last year and Electrum as you may know is like one of the most used and widely popular wallets and they also enable the JSON RPC over HTTP by default and it had no password protection so every website that you go to could in fact steal your privacy at least and your coins at best or the other way. Not only websites can do this also like if you're a shared web server or if you have users on your machine or maybe you know you have a local Apache running and there's a guy that can hack in and escalates privileges to the user WWW-user then they can of course just scan the local ports and access your server even if it's a different user. Of course without saying if you have authentication you should also use SSL otherwise people can just sniff your authentication and I think I have to check but I think I need to file an issue also with Electrum they still don't have SSL there. Fishing is one of the worst problems in the world wide web because it can be arbitrarily sophisticated like there's no real way to just eliminate the threat of it. It's just a red trace. You could go to of course you know classics malicious wallet, download malicious wallet, go to a malicious web wallet. Guy from the Monero community, the Hayoho guy made a nice instructional post so this wasn't real but I was showing how you can buy a VPS and some adverts and make a fake URL like with the small unicode O very subtle so no one will see this to scan people into going to my Monero and giving after private keys. And you know there is something you can do about this which is use hardware especially U2F and hardware wallets they go a very, very long way in solving a lot of the problems. Of course it's not fail safe but it helps a lot. Like Google mentioned they haven't had a single fishing attempt, a successful fishing attempt since they introduced or required U2F. Even more than using U2F and hardware wallets which help you because you know you don't give up your private keys, you actually have to confirm manually on your device that you're giving up your coins. The hardware wallets can help you if they implement something like whitelist. So this is an excerpt from the Bitbox firmware. Like couple of web wallets are just whitelisted and if you connect anywhere else it just doesn't work and couple of our users send us thank you notes because they went on myforwallets.com or whatever and they couldn't connect and they were happy that nothing worse happened. I'm toying with an idea it's like early stage I don't know but like in the web you can eliminate fishing attempts this way because the browser makes sure that the URL is encoded in the U2F protocol but what if you download a native app which in many ways is more secure than a U2F but there you're out of luck. I'm thinking maybe you could use hardware to install or launch any kind of wallets locally after making integrity checks. Also please like I don't see nearly enough services supporting U2F like there's Dropbox and GitHub etc but I'm thinking Bitcoin exchanges, Monero exchanges like all of them still are stuck with Google authenticator which is not secure. I wanna do a brief note on the choice of the text tech if you wanna build a web wallet or a wallet and I don't wanna go into you know too many of the hot topics where people debate if this is better or not. Just wanna make couple points here. One is that if you have a web wallet in the browser even though you might be safer from fishing attacks a browser is just a wild west of security like I mean everything goes especially if you have a malicious browser prevention that then subverts your fishing prevention like they can just put in arbitrary data and you know you can I know you can ask the user to move their funds to a secure location because Trezor said so but it's not Trezor it's just some extension. All of those web wallets would be probably better off packaging just in a native app. Of course the most popular one is Electrum a lot of apps run on Electrum I'm not a big fan it has issues because in the front end as well as in the back end there's JavaScript so the bridge to you know remote code execution is very small you just have to find a small hole and then you have access to everything and not send bugs by default end and end but there's other easier ways you can use QT with web engine or you could use the Chromium embedded framework they are more secure and also just almost just as easy to actually build. You know most people use web front ends because they are easier to build. They use less resources you have more talent more access to people can use it but of course if you have the resources you know skip the web part altogether and do native like when Erugui is a great example. Yeah quick note on programming languages as I said before if you use JavaScript in the front end and back end you might have some issues if you see a lot of memory issues really hard to get rid of even if you are very careful and people tend to gravitate towards those two languages because they run everywhere like JavaScript on some Android iOS C++ as well and you know practically every wallet is one of those two languages nowadays and I just want to make the point that since maybe last year and go and Rust and other languages that compile to C are a very viable alternative and you can use them effectively to make a full application on Android iOS Mac Windows Linux server and you know you don't have any remote execution well no buffer or flows no smash protection that you have to put in place and privacy it's not only about security if you leak your privacy you're also not secure I don't want to go too much into why privacy matters I want to just refer you to this great guy Glenn Greenwald and check out this YouTube video it's amazing. Today's wallet leak your privacy for example before blockchain.info's Android wallet if you go to random.org then they know and their provider knows and their hosting center knows that you're using this Android wallet which is not great you know if you use Electrum servers if you use My Monero any web wallet treasure if they connect to a server you're leaking privacy maybe not to the same level but you are we can educate users about VPN and Tor and integrate it into the wallet and make it a one click experience but I think this is still probably not feasible or too hard I want to you know encourage every wallet offer to be to enable the user to connect your own full node and our wallet that we just recently released for the Bitbox does that from the start like I think it's very important but more so I want to dream about the world where everyone has a plug and play node that they can install next to the router and it's just everything in a very simple manner and with a bit of luck we can reach that goal like a shift we've been tying a little bit with the idea like an intern made some mocks and we are tying with the idea how or if this would be a good you know good future I do think this would be amazing so where does this leave us with Monero you have noticed that my talk has been focused mostly on Bitcoin and stuff like that other coins in Monero the current state is that they are Monero is a little bit behind Bitcoin maybe a couple of years in terms of the wallet experience there is Monero GUI and Monero and Client there is mymonero.com and that's basically it that's that's what the date and my Monero makes no like effort to be secure it's by chat by deliberate they have a really nice disclaimer that it's not secure so that's okay the Monero GUI is awesome it is a full node it runs everything is good but of course users will want to have light clients eventually because running your node is very difficult especially so so I expect in the next couple of years to see a lot more like wallets being implemented for Monero on various platforms and then maybe you can take away some of that today thank you which implications so institutions have different requirements than end users mostly and as of today there is no good solutions for institutions to start doing real business on top of crypto but a lot of companies are in the space like trying to make those solutions yeah if you're gonna have a hard time as an institution just pull together some of the existing clients and hardware wallets and do something on your own it works most like banks and institutions are doing it today to crazy amounts of money but I wouldn't recommend it and solutions are being rolled out as we speak I haven't thought about it a lot I don't think well intuitively speaking I don't think verifiable remote hardware works I might be wrong although it still might be a reasonable solution there's never you're secure or insecure there's levels and if you can have a remote hardware which you can trust in some ways but not fully then that's good and it's a step in the direct direction still in the end I think it's best if you can have your own at home also like your own node if you buy it from a company like us then how do you trust that like the goal is of course also to have an instruction to build it yourself with off the shelf very cheap hardware and all that stuff I'll get it, come again I'll talk about Monero is the first choice for what, sorry so I was asking that this coin maybe because of privacy it's kind of first choice for the actors like exploit kids they drop the crime wares and any crime wares that involve crypto miners do you really drop for Monero? I still couldn't get the part of Monero I think you're asking if about malicious activity of Monero and privacy right so I just want to refer you to this one over here I urge you to watch it like this mirrors my view on privacy thank you yeah thank you