Hardening Smart Contracts with Hardware Security

can I talk today I'm Nikolas co-founder and CTO Fletcher manufacturer of fine other wallet I talked to there would be about hardening smart contract with hardware security an alternative title could be who to build how to design a platform to design hardware wallets on different kind of secure hardware so let's move forward so first why do you why do we need to secure smart contracts because smart contracts themselves are extremely secure they are running into the ETM VM blockchain I mean they are secured by the consensus is securing smart contracts but there are some nasty things that could happen around the edges if we look at the right thing first mat contract can receive data from external sources so here this external source which is a picture from Delfy who as you know is telling the future so some people are calling that Oracle's I decided to stop doing that after getting some nasty gram from a database or designing company but you get the idea so if they are not twisted the smart contract can act and perform some mistakes on the other hand smart contract are interacting with users who are holding keys so generic user PC is not extremely secure also as you can see here so we need to secure key protection here we have two items to secure and we'll see how secure Hardware can help with that so what kind of rights can we get against the edges first we can consider malware so we are very done malware which will just steal private keys or smart or malware that can manipulate contracts I'll just feed bad data to the user first then we have physical attacks so we can have messy physical attacks with which are extremely powerful if the algorithms are not properly define an attacker can manage by looking at the chip power consumption or significative things I mean changing with a chip can retrieve private keys and can basically steal that from the executing process then physical attacks requiring access to the chip itself which can be leveraged on to change the behavior of the chip by performing some glitching attacks so here people might think that glitching is going to open something glitching is a bit more complex it will change the way the process is running basically so it's still extremely powerful it's not easy to get right but if you manage to glitch an item if you managed to glitch a physical device the right way you can also extract keys so we have to consider all those frights when dealing with secure hardware so secure other way here we'll be bringing an isolated environment to run the different applications so we want secure hardware that let us execute code otherwise we can't do much we want ideally secure hardware that is physically resistant so secure Hardware on which it's hard to extract data sick we also want secure adware to give us proof of execution on the platform so when we run code and secure hardware we must be able to be able to prove to an external party that the platform is healthy so that the platform has not been broken into and that the code running into the hardware has been running into the right platform and ideally if depending on the hardware were running on we might want to we might and we might want to strengthen the cryptographic primitives to prevent the passes to prevent the passive attacks we have been talking about before so when considering secure Hardware people do not feel comfortable about them because of because of binary blobs and NGA's around secure hardware but the general idea here is that today we don't have any kind of open hardware really available if you look closely into the different architecture of the hardware that you are using you never fully own your hardware I mean at least for all generic for all general-purpose computers available today on your CPU people can modify the microcode of your CPU so the way it behaves if you are using an stm32 which is a very common when microcontroller use for hardware wallets you don't really know how the chip is behaving itself as well because it has critical parts regarding to the related to the security of the chip itself so I am taking a pragmatic approach about that I'm basically considering that secure hardware is considered to be best of class right to protect data and if it's available and if we think about the different threats and if we try to limit them it seems safe to use it and it's still open it's still open enough and on a small point I mean if you are using as if you are using an Intel CPU today and you don't want to use SGX I would just remind you that you are already using the management engine which can do a lot of stuff behind your back so if you are using the management in giant for the bad parts we can also use it was a good parts small very quick history of secure hardware so the general idea here is that secure hardware is getting more open over time so initially everything started with smart cards in CIT smart cards were not very powerful and when I'm not easy to use you had to buy a specific video to use them they were absolutely not internet friendly in 2005 yubico innovated with something more sophisticated on which you could bring user presence and you didn't need a reader but still the chip was not very powerful and not extremely open and we have seen really a new set of secure hardware coming with cryptocurrencies because how do I wallets have been designed to be able to work in an extremely hostile environment in which malware could change things on the user computer and the hardware wallet had to always operate properly otherwise people would be losing money so I'm considering Hardware wallets today as the next evolution in smart cards because they are really smart cards design foreigners v environment and for the internet if we look now at the history of generic hardware so wide secure hard way is getting mopin generic how do I is getting more secure so they will meet at some point that's the idea so here initially if we if we want to consider the generate CPUs I'm introduced redzone which I'll set up very low level primitives that you can use to basically create operating system that will easily tip applications and create a normal world and a secure world in which secure application can execute without being interrupted by the operating system Intel did the same thing a bit later the platform is more rich so while Trustin only provides primitives in hgx is providing a set of API that you can use to run any kind of application without writing the operating system yourself and then a bit later we have seen some evolutions of tours on and mostly trails on coming with hardware components optimizing cryptographic primitives that we have been talking about before and one interesting chip if you want to look at that it is all the latest chip are including ble from Nordic which has chosen which has frozen and a cryptographic accelerator so those chips are extremely close to secure element today they don't have exactly the same physical properties I mean regarding resistance to hardware attacks and proving the origin of the chip but otherwise they are they are extremely close so now what do we what is a hardware wallet and what do we want to build if we are splitting the different parts of hardware wallet into an architecture that I will call the transaction interface so the transaction interface will interact with secret data which is basically as the seed of the user if we are considering if we are considering keys and if you are considering deriving keys several applications will be interacting with those keys we don't want those applications who interact directly with the secrets otherwise they can steal the secrets and we want to iterate the applications from each other so applications have to call the transaction interface over a secured pass which won't reveal the secret and will only let them run a specific set of of algorithms and further we can lock the applications on several properties for example we can lock them on an HDD revision pass which means that here if an application gets compromised the only derivation pass that can leak is a specific is past specific to this application so here I'm referring to your article deterministic wallets which are getting used on now significantly I mean for for atrium and have been used in Bitcoin for a long time but we can generalize a concept for all set of keys how do we so what kind of components do we need to build the transaction in their place and secure Hardware we need to build the iteration first so because if we want to run several applications together we need to isolate them and we need to easily the part into writing with secret data from the applications then we need to guarantee secure storage we need to guarantee a secure implementation of the cryptographic primitives so referring to the passive attacks that we talked about before and then we need to make we need to provide a way for the external party to verify that the platform is legitimate and that an application running on the platform is legitimate and on top of that because we are running in a world with smart contracts we want to provide a way to authenticate this on chain so typically we want to be able to prove and change that we are running the right application on the right platform and now we will see how to implement this different components on different hardware and the consequences so first why are we designing a traditional interface rather than running with a set of different applications point is we are saving time by in doing that rather than just letting each provider design his own set of applications as we've seen before formal validation is quite complicated so that's just an example if we want a formal validation of a secure Hardware it's better to do it on a common interface than to duplicate the work on a set of applications so here the right parts has a critical path the transaction interface is critical and all the stubs are that the others that the other application would call which are still executing in the secure world are protected by the transaction interface so you don't need to spend too much time in that case validating them because the platform will already guarantee that they can't leak thanks to the iteration properties if we want to implement that on arm so that's regular the most regular use case which will be completely native we can use the native properties of an see of arm CPUs to do that so we can iterate the secrets using memory management you need our memory protection unit and when the course that will be done over from the applications to the transaction in their face can be directly mapped to arm service calls so here the architecture is extremely close to the first one we are just replacing all the calls and all the iteration by native arm properties and the applications themselves are native we don't need to run a VM when you are using arm because the hardware is allowing is allowing us to perform the iteration by itself now let's consider hgx so hgx is kind of different we don't have ax we don't work close to the metal we can't really easy right enclaves so enclaves being application running an edge reacts from each other we don't have either and attestation schemes that can run on chain so the attestation scheme and HTX is Intel proprietary and we have to call a server on Intel side to guarantee that the platform is legitimate so in this case our one simple use case that I suggest is to use a virtual CPU so it might look complex to use a virtual CPU but thankfully there are things like Moxie which happens was already very easy to test and already almost problem I would say so it has been used by different projects in the Bitcoin space and why would we use that rather than the AVM the most I mean the easiest reason is that if we want to guarantee Portability and easy possibility between different secure environment targeting C is a good call because when we are when we will be working on arm we will have native iteration and here we simulate the native iteration by running with virtual CPUs so of course just a situation I would say this architecture is completely open for for comments and don't hesitate to for some other ideas now secure storage so how are we going to unload secure storage depending on the platforms if we are running on our own platform natively and we don't have any problem because we can just stop things natively on the platform if we are running on a host on which we can store anything which is an example for enclaves and HDX we have to be a little bit more creative in this case so one way to do that is every time move on to use secret data we can encrypt it by a key which is owned by the application running into HDX running into the secure environment we can store this on the host because then it's not dangerous because this I mean this blob is encrypted and cannot be cannot be used by the host and when we want to use it we will just pass it back to the Enclave we can also choose to bind the data to different items so we can bind it to the interface itself we can bind it to the device or we can bind it to a specific application so we have all kind of granularity in the way we relate secrets from other applications even when running on an enclave we still have some some problems if we want to consider secure storage on Enclave so on which we can store things natively typically on TV play is a critical feature if we want to implement a pin counter and we don't have on TV play it's not going to work because then people can just push you the same counter over and over again and you just can't do that so one way to overcome this this limitation is to use monotonic contours monitoring contours would be counter that and can only go forward and this is guaranteed by hardware so in this case we would use a monetary contour put it in the object reference store the value increase it when we want to change it and it's fine because this can't be replayed this can be replayed depending on the condition we have for the implementation of monotonic contours on the platform so here again keeping in mind that you have to consider all threats when implementing something you want to verify typically if there is a reset condition for monetary control and how that would work now something else to consider specifically for SGX let's say you want to migrate data from one Enclave to another you have to consider if you want to lock your secrets to your applications or lock your secrets to your issuer if you lock to your application then secure I mean security wise is quite safe because if the application is modified you are losing secrets but it's not that nice for the end-user because then you have to repose analyze everything if you lock to the issuer everybody can update the application but if you lose the issuer key then you are going to be you are going to be able to compromise all user data by just deploying your own Enclave so here again you have a trade-off to perform between security and usability and think carefully about it now regarding the implementation of cryptographic primitives you have basically two choices you can use cryptographic primitives given to you by the platform with guarantees that they are going to behave very well and they are going to resist all kind of all kind of side-channel attacks or you can use open source crypto history has proven so far that it's better to use open source crypto so if you have been following security news in an infinite library as some issues recently so here well we have good typical choices to implement several cryptographic primitives are coming from Bitcoin we have lipstick P 256 K 1 and CT AES IES and we have also open source libraries for different kind of crypto switch have been tested again side channel attacks and which are reliable I would consider too I would consider to exert extreme caution when picking a cryptographic library because there are a lot of open source cryptographic libraries when where these attacks have not been considered but thanks to different cryptocurrency projects I've already picked some good libraries for us so we can use that in all trades as well now the proof of execution if we want to prove that something has been running on the trusted platform and on the blockchain the easiest way to do that is to just include the hash of the application into a primitive that we will call to let an application sign a message we can do that because the iteration and join is knowing which application is running and so can intercept the call insert the hash of the application in the middle and walk further with that so by implementing this we have something that extremely easy to verify unchain because it's just a signature and typically is as always this has already been implemented by our class and there is an example you can you can you can check on hgx the way we will do that is we will go through one step we will call IAS so we'll call the Intel attestation service at some point because that's necessary to initiate the chain of trust and then we will continue the chain of trust from from ourselves so in the end we end up with applications that we can verify on chain even if they are running on an hgx Enclave with an attestation which is not supposed to run on chain but we might still want from time to time to check the health of the platform because the state of an enclave can change over time typically if there are bugs of or exploit that's the case today there is a bug that's going to be patched by Intel shortly so we we have a system that we can verify or unchain we still have to pay some attention on who we are going to patch it several use case we can have with all those systems so we can first this decide to replace hardware wallets and visualize hardware wallets but to do that we first need to have a twisted display and twisted input because one of the key part of hardware wallets is not lying to the user when displaying something and waiting for the user input before actually performing an action if you want to do that we need specific primitives that might be not implemented by all platforms typically on hgx we will need the twisted display school PGD whole body heat protection display projection display sorry we need to have this implemented if we want to have a user wallet which is similar to a consumer product we can still perform some we have some mitigations if we don't have PTV typically we can use to unclip to have one acting as a secure screen and one binding to the other but yeah that's kind of a hack and not extremely comfortable if you tell two users that you are going to make their life easier but still require need to have two devices to work properly another use case which is probably more useful and easier to deploy in that case is to use to create a usage specific hardware wallet so how do I wallet that would look for specific contracts for specific addresses for specific limits or code size that you want to implement on the under system so that's easy to deploy even if you don't have a twisted input question is you might wonder why this is better than a smart contract implementation that could do all this by itself so first if you want to deploy this on a device it's a great way to make sure that your device keys won't be stolen to do something else which is still compact is enforcing things and then you can create more flexible update rules if you want to update a smart contract today either you have to think about it before creating it or you would have to empty it and transfer its funds as well so doing that with hardware might be more convenient in in many use cases you can also use the service to create external services that you can verify so the on demas random Oracle is an example also for moralize creating a random source and verifying that the random has been generated by a trusted platform and finally so speaking about those architecture we have an implementation running the prototype that you can already play with so I'm taking all kind of suggestions about it today's a reason implementation walking on hgx there will be one walking on arm shortly next year so it's heavy walking polar ice just to let you know we don't have yet an ATM one at available but you will find all cryptographic primitives and if you want to start playing with it and then asking some questions well I'm around let's get the conversation started [Music]