J3 SAY 06 Nicolas Bacca Securing decentralized exchanges with hardware wallets

okay so good afternoon at DHCC I'm Nicola Beck a CTO and co-founder of Fletcher and today and surprisingly I will be talking about hardware wallets and most specifically I will be talking about how we can use Hardware wallet to have an decentralized exchanges so that will be mostly a list of issues I have run into while trying to do so a few solutions and a lot of open questions for everybody that we can discuss after or later tonight during the nice party that I said will be organizing so first a reminder I mean just in case people here don't have many ads are not very familiar with hardware wallets so the goal of hardware wallet it to protect your private keys because if we look at the traditional user computer on the Left it's not very well protected and it's not in a very good state so you want to protect your assets your private key against people that may want to steal them or against people that might want just to corrupt what you are doing for whatever reason for fun hotspot or anything you have plenty of ways to corrupt your actions on a tearoom because you are interacting with smart contracts and basically the goal of the hardware wallet in that case is most not just to protect your keys but the hardware wallet must tell you exactly what you are trying to do and how you are trying to interact with your contract so an atrium the hardware wallet as a specific functionality of letting you know that you are doing the right thing so for example here if you are playing a dice you want to know that you are willing the dice you don't want to be performing any other action so the hardware wallet should be smart enough to let you do that and that's one of the reason why interacting with decentralize exchanges is interesting so why so first because I think the architecture of the centralized exchange is pretty interesting by itself so it's a kind of the ultimate step into the centralization today we have a lot of we have a lot of systems so most of the exchanges on tour eyes we have a few eBridge system like at Phoenix for example using the liquidity of centralized exchanges with the peer-to-peer aspect of decentralized exchanges we have fully decentralized exchanges like as well as your eggs also we have seen that who isn't before so the architecture is interesting and it's a good match for hardware wallets because how do our wallets I mean to own your keys and couple with the centralized exchanges it would be a full way to trade freely you have your keys you have your transaction and you can check both and yes another thing is that it's an interesting problem because it brings a lot of new user BDC problems that can help how do i wallet making be better and it can improve hardware wallets for all kind of contract based applications so first you need to want you need to have your hardware wallet interacting with your decks as easily as possible which means it should be transparent to integrate your hardware wallet into your browser then you have to provide clear information to the end-user you want ideally to visualize your trade or the action that you are performing in a very clear way and you want to prevent creative scams because decentralized exchange isn't about contracting or can open the door to a lot of very nice scams so today we have only seen I would say very common or boring scams but I will get a bit more into the different security issues that we have and we see that there is still a lot of potential for people who would like to steal money so where are we today so first maybe to start with what we have accomplished so far so mostly thanks to the ATM community because we provided the api's but everybody has been doing the integration by themselves so thanks to everybody here so we have been integrated into the 0x protocol and relay O's so basically an integration into this your keys library and then having the Elwha wallet playing fine with all the websites so we are in the into baddha relay projects d/dx and we have been integrated into other specific exchanges which have their own protocols with a delta Qyburn ID exit so i might forget a few people so sorry about that and more people are working on it so why are we here today we are here today because we have a nice JavaScript API that people can look at and that will let you integrate hardware wallet into your that very easily so the initial integration was done I did it for my our wallet about two years ago it has completely changed thanks to guy Tom who has been repackaging our applications into something that looks into a proper JavaScript project so if you looked at it in the past I would suggest giving it another look because now it really looks very nice I mean it's completely different so we have a sub provider if you want to integrate into something like meta mask and couple it with another word free provider and we have a starter kit if you want to design your own application and you want just to access the hardware wallet so you have with those two links you should find anything you want then why are we working so why are we working fine with a browser today so first on we are looking to have a plug-and-play integration into the browser so if we look a bit into the stone that we started from something completely different so we started from you - f you - f is supposed to be the model infeasible protocol which is based on a cryptographic challenge between a website and a physical token so it's all things that was developed by Google in 2012 I think the idea that you have to set of six you have to set of messages a registration where the device is generating a private key and returning the unencrypted private key to a server so which means that you can have an unlimited number of website handled by a simple token and then an authentication where the token is performing a challenge against what the server would be asking so you will be sending the private key encrypted to the token token will decrypt it sign the challenge return the signature so here from there you might wonder how are we talking to a hardware wallet using that kind of protocol because that an authentication protocol that not something to correspond contract so here is the catch we can use on the key handle here which is just an encrypted blood to pass a comment and instead of a signature we can send back a response so by doing that we managed to have a simple hack and the u2f protocol and turning it into a kind of a proxy eternal to be able to talk to any kind of device so there are just two drawbacks so first it's a high so it might be removed but so far it has been working well for more than two years we have no events when the device is connected or disconnected which is kind of a limitation if you want to perform if you want to have a nice UX but we can still work with it and on the plus side the application ID is a browser guaranteed hash of the web origin you're currently browsing so we'll see where we can use that but it's very well it's a nice feature to add because you basically the device knows where it is on the web and we can use that to provide more information to the user so that's what we have today in the future we want to move into standards which will be a bit most on that so Web USB will be a good start so Web USB is not a hack so it's a proper protocol to talk to a USB device on the web it will have mobile support so at least on Android you will get device connected and disconnected events but you lose you lose the web origin and I would say that Web USB had kind of a bumpy start so far so it has been integrated into Chrome it was disabled recently because people realized that it gave a way to access you to have two tokens some kind of u2f tokens differently so people managed to fish the unfishable protocol using web USB by basically connecting to an interface that was not enumerated and accessing the u2f applied in a way that was not supposed to be done so basically changing the origin and another way to move to a plug-and-play browser integration will be the web Bluetooth protocol so for different kind of hardware wallets that will be able to communicate with mobile devices so when we do that we have basically a protection of private keys when we want to transact but there are lots of other attacks that can be done under the centralized exchange so first we can wonder if we are interacting with the right website so that the simplest kind of attack then are we interacting with the right smart contract what can be changed on the contract itself and the token will be swapping the website will be swapping tokens but are we interacting with the right token I mean can we be fooled into swapping something that we didn't want to swap initially and then a more specific attack on the protocol itself when we're interacting with the smart contracts are we really passing the right message for example 0x is based as a protocol to define orders what happens is though if those orders are different and how can we display them properly on the hard wallet so first integration with what with the right website this has been a source of attack in the past so for example with the tail Delta which was the DNS was changed when the website was acquired and well it was a very simple attack but people managed to collect private keys so u2f here can help if we look at the application ID because it means that we have a way to if we're able to make a map between the hashes and the websites the hardware wallet will be able to display the information and we'll be able to verify that we are really interacting with each other for example problem is that if we do that then we realize quickly that we need a trusted store of web origin hashes and well for people who have been watching that TCR talk yesterday so for them talking curated registries they have seen that it's an open problem and under hardware device it's even harder because we have in a way I mean if we want to add a trusted source something we would basically need an external party to do it to sign it and to pass back the token to the hardware wallet so not very convenient then how do we verify that you are interacting with the right map contract so on that ens can help on the host because we can map names to smart contract addresses but if we want to validate ens on the device and it's more complicated because of course the device has no real access to the blockchain and cannot really verify the state of any honest name another problem is that TNS is not going to prevent current attack on website which is Oh sweating so if for example you have a delta and somebody's which is virtue stirring at a delta with 2l or 1 e replacing the L it's not going to help a lot so again it looks like we need another trusted sir but this time that can run on the hardware wallet also and mappings not contracts to their names now interacting with the right token again it's still a naming problem so token is represented as an address we need to have a way to map token names to token addresses so I know the trusted store starting to get well a bit boring here now how are we going to verify that we are communicating right with a smart contrite so for that we need to validate the EBI but validating the ABI on the device itself will provide a very poor UX because we don't have a very specific name in the ABI and people don't want to read binary so you don't want to verify when you see a trade you don't want to see the exactly see more data that you are passing and validating what you're doing so here you might also need another level of abstraction when you interact with the contract for example a blob can be a message a blood can be an order or blood can be an address so how are we going to display that on Z Hardwar wallet and what kind of specification can we had for that if we look at the argument of the smart contrite let's say we are going to sign a message so if we sign a message there is an EIP for easier message message signing where you can pass on the argument of the message and verify that you are correctly signing the right argument so you would get an information for example that this field is a string this still is an integer and displayed that way instead of displaying a binary blood but here we also have a UX problem it's still too low level typically there is a field in the zero exposure call probably not very visible here but there is a time at some point the time should be represented in a way that is readable by the user so do we want to present an absolute time do we want to present a time related to transition do we want to do we have a source of time in the wallet itself so you see that in that case trying to make something generic is still very hard so proposal for that reverse AB it's a problem and think that we won't manage to create something that is completely standard to display what the contract is doing and to sign messages and turn into small applications that we can basically provide along the DAP which will be loaded into the hardware wallet adding so just adding a few additional trusts to the different a woman well it's manufacturers so here I said ok we have to have a wallet manufacturers of course we can have more and they will just provide it or additions so first they will manage a trusted star of token so they can give you an association that will map the token to a name and regarding the code they can give permission to the contract author to write an application that will handle transactions specifically for his contract and that can sign messages that are matching the EIP seven one two description so that means that here we provide the responsibility from the hardware wallet to the DAP developer to create a small application running and the hardware wallet that will be responsible for signing transaction going to this address messages are mapping the specification but leaving a full UX rights to the developer so that way we can imagine a set of small application that will be loaded along the dad and on which people will just be able to handle everything regarding the UX while interacting only in the scope of the comte right so this is an addition this is an additional protection I would say to what exists today because today so hard wallets are only running application signed by the manufacturer typically here we would sign we would sign we would run delegated rights for application related to specific contract so what would we know what would we need for that dynamic application management and the hardware wallet first so that's something that we already have in our infrastructure and that's going to be I think not too hard to make with third-party architectures for example a lot of people are looking into bitin today if you want to make something like this in baton you won't be able to do it directly with the script but we could think about a long wait running on top of Python which could describe that so the issue is still to map a UI to different devices because other wallets can add very different UI's so some will have a screen some will have a touch screen some will have a cross screen some will only have a few LEDs few buttons so it's better if that part is native and still belonging to the hard wallet manufacturer but that's open for description if we want so not as API what do we want this application doing so it needs to sign things for sure but does it need to do more to still open for description and what kind of language can we have for that so Python can be something to look at see the bit complex to run for some architectures something else so still open for discussion today with our architecture we can design third-party application in C so that what we have been doing for few decentralizing changes we would have some things to show on that so shortly I would say in the coming months and so we would have those that LEDs running around along the main interim application and able to display specific messages are regarding regarding the spot regarding the tax which is currently running so well in our architecture we just design applications that way that's fully opened for description for other architectures of course and well we're interested to think about ways to describe how those small application could look like and if people would be interested to run them on other medias so thank you you have time for questions how much of these things are already done so in a proprietary way I would say a lot of it the problem would be to turn it into something that's done that ice that's where that's where the trouble is today but running an application that will run alongside our main interim application today and irrigate the contract signing that that's already done so that's already done with our model where we run everything in C now well the remaining part is very open for discussion these designing something standard around that because today it runs basically within nature platform but let's say if we want to design a standard set of API to describe applications running into Hardware wallets that's where we need to talk earlier um yeah how about standardization have you been cooperating with others do you see this is something that you're just gonna have are you gonna open this up and standardize on it I think that we will start well we'll start by opening we'll start by opening what we have then we'll discuss I think that today so other people are converging around pattern architecture to describe applications so we'll probably think about the common set of features we can have which would be very simple initially around well our C model and all the Pythons models so it can be just signing an app or moving a field around or describing what the time looks like all those kind of things and I guess we can start small and well see what we can build from there yeah it's just wondering as we move towards slightly different kinds of transactional models and things like state channels and some of the new alternatives that might help us with scalability just really curious to hear your thoughts on on how hardware wallets my support that and and and and thinking about how users enter into those kind of agreements and get out of them yeah I think I think that we are going closer to the same model so but basically the hardware wallets will turn into execution and giants and giants those specific applications and that developers will be able to design along their main contract small part of the contractors will run into the hardware wallet run either the specific crypto other specific UX I think that we will probably need to run into that level of complexity for all applications are ultimately because if we want to try to specify your common UX for for everybody is going to be a bit messy [Applause]