 Hi everybody, so maybe you are not coming for this talk, so I have an explanation for that Which is right there So well, I can try to convince that this is the talk you are coming from you are coming from but it will probably not work So my initial talk was rejected and I got a notification like yesterday at midnight that in fact it was not rejected So I decided to recycle some slides I had for SGX add a bit more content and that's what the talk will be about So if you have a medical condition and you can't listen to an SGX talk, you might leave I won't be offended otherwise. It should be interesting. So With that We are going to talk so a little bit more about our own clave The idea is to keep talking about what we did last year previously, which was not very successful We will discuss why and we will discuss how we can improve that and Well, if you want to follow something for example during the talk and to read something during the talk So threat model we have in the read me is interesting to read and it's still up to date even if the code is not So first question you can ask why are we making an enclave as a hardware wallet manufacturer? So the first thing is that we are ledger has been developing into several industries and created several business units today So we are not only making hardware wallets with the se on which we can code our own OS We are exploring the custodian model where we work on HSN that are not Built by us. So in that case we need to work into some things that looks a little bit like an enclave And we want to transition from a company manufacturing hardware devices to a company selling operating system licenses and for that enclave are very good target because they already exist They are already in the market and the main obstacle today for people to use a ledger is actually to buy a ledger So if we could find a way to download a ledger and have an interesting security and an existing computer It would be quite interesting for us And so that's why we are digging into those models and we are evaluating the security very Toughly for that. So we have a really reusable operating system code base working on an enclave and Changing from a secure element to an enclave for us is quite easy. So we are using this. We are using this expertise and Another important thing is that well, we have a strong Expertise in hardening cryptographic code and this is something that's difficult to do I mean that's something that you don't usually do because a lot of people using secure elements We just reuse a vendor cryptographic library We build them from scratch and we reuse Everything that we have on the chip to make them harder. So we did a popular CTF This year on our device that was worn by a company called Ninja Labs They liked the CTF. They didn't describe everything yet, but it is related to Side channels and to template profiling on side channels. So that's the kind of things we want to do an SGX as well improve it and Provide the result to everybody So if you want to transition from a hardware wallet to Virtual secure device or to have enclave you have to consider a few things First you want to focus on the key protection. So key protection is the most important part of a hardware wallet It's going to be very important for an enclave as well You don't want an attacker to be able to extract keys So here for an enclave we will focus on software threat models So we will not consider hardware threat models where an attacker has access to the enclave Because that's pretty much out of scope I mean enclave are quite complex and it's difficult to to focus on securing as a whole thing against the physical attacker then user confirmation is Extremely important as well because if your enclave is holding keys But users can an attacker or malware can sign anything It's not very secure So you should be able to confirm what you are doing and you should be it shouldn't be possible to fake this Confirmation if you are malware then flexibility you should be able to do software updates on your hardware wallet or enclave any time So even if your computer is compromised, which is quite important and As a developer you should be able to test new functionalities Typically for Ethereum if your enclave is signing an Ethereum transaction It should be able to support smart contracts and it should be able if Possible to display specific UX for specific smart contracts in order to provide always the best and the clearest message to the user to know what you are doing finally Remote attestation we should have a way in an enclave or in Like we have in the device to verify that the code is running on a healthy platform And that you are running the right code so you should be able to verify which code you're running and we'll see that this comes with With some difficulties on HTX, but we can help solving that as well So today in our architecture the way we achieve source code portability between secure element and enclaves is quite simple We focus on C source code portability So we write the code once with the same API when we work natively on a secure element We are compiling to arm because our secure element are based on secure secure core Also, which is an kind of a secure arm and when we are working on an enclave all kind of enclave So it could be HTX a TE or an HSM We are cross compiling to Moxie which is an open architecture Which was used usually in the which was used previously sorry in the Bitcoin project as an experiment by Jeff Garthick back in the days But it's very simple. It's very easy to review easy to secure as well So it's a good target if you want to have a simple VM Regaining the architecture itself We will try to reuse this model as much as we can so we want to protect the user secrets So we will the user secrets will sit between a kind of a firewall applications will be firewall between each other as well and When an application wants to access some cryptographic material it will use It will use a service call so service call on arm or something else in a virtual machine to access the secrets So applications can't touch secrets unless they enter a privileged mode, which is run by the kernel and Applications are isolated and of course can't touch the kernel So if we look at the state of our SGX stack in 2017 We had good points and bad points. So the first good point is that it works So if you want to try it today, you can do something you can run some simple applications You can we demonstrated on chain attestations So you can verify that your enclave is legitimate on chain after you pass Intel attestation You can verify that your code is the code that is supposed to be on chain And we have an open-source SDK even if the code is deprecated It's still completely usable and you can still play with it on the bad side on the negative side You we had no user confirmation possible since we didn't have a display API So you couldn't use it really as a wallet So if all code that you wanted to run on the enclave had to be signed by us so that the biggest Things that deterred people from using the enclave because at some point if you wanted to run with in a protected environment You had to send us the code or we had to sign a key which was more convenient But still a lot of people didn't want to contact us for that So that's why in my opinion it wasn't very popular and of course we did no security audit So the code is really sent to you to be to be tried and without any kind of guarantee So how can we improve that? Of course regarding the attestation well people have been talking about Intel attestation a lot So the thing is the Intel attestation today is still very useful in my opinion because you need to validate the platform health from time to time For example when there is a new security exploit that involves updating your BIOS Updating the microcode of your CPU The only way to know that is to have a centralized API at some point So it's still used today, but you can select different setups depending what you want for your application when you are using around clave So if you don't want to use Intel attestation you can it works the code is still secure because the code is signed So you can verify you can rebuild the code on your side and verify that the code is correct But in this case you don't get remote attestation at all It's a choice if you want to run your wallet on your side You can do that maybe not the best choice, but it's a choice You can run Intel attestation once if you do that you get a weak ledger attestation I put weak here because it will not be up to date regarding the health of your platform which can change So it's again. It's a choice But if you do Intel it if you run Intel attestation from time to time then you can get a stronger attestation and The biggest difference here according to compared to IS attestation today Is that it's something you can validate on chain? so The good news is that with a new Intel API called protected transaction display We can solve two problems So we can solve the confirmation issue and we can solve the fact that you couldn't run anonymous code So far. So now you won't have to contact us to run your code on the enclave once this is released So if we want to summarize Very quickly get another view of protected transaction display It will be a way to create a secure display to display something securely So on your own device that will be Prepared by the enclave. So the way this works is that PTD will allow you to create Confidential output on display So the display here is a mixed display is in this window. You have a mixed display So some is done by PTD. So can't be spied on by the host So pin pad here is done by PTD This line is displayed by PTD and this line is displayed by PTD as well. So buttons are not and this Label and string are not So the inputs the output is confidential because the host cannot read anything and With the fact that you can display Pin code that is randomly swapped by PTD You can achieve confidential input as well because if for example here you type your pin code The host has no way to know that you type one two three four if you click that I mean the host will just see that you click some Patterns on your screen but this way you can manage to have some secure input even if it's not very convenient and Here we have a way to display some additional data on PTD. So You see an amount Which is an amount of zero point zero zero nine six eight years So here you see the number of decimal below which is again not the best UI, but well I'm that's what you can do today and part of an Ethereum address So after you do that after you enter your pin a wallet could send an Ethereum transaction The limitations we have repeated it today as they eat the output is confidential So the output cannot be spied on But it cannot be trusted because you can still display something on top of the output. So in this case That's why we are that's why we are you have to do this user confirmation twice So it's not the best you X possible, but I would say it works with what is available there So the IO primitives are very limited today. That's probably some things that can change But you don't have the flexibility of global platform TE trusted UI if you want So one thing that's popular and with this API is to basically register an image on a server and then display this image So you can be sure that nobody can intercept the image and A malware on the host could not replace the trusted UI, but you can't in that case So that's why you have to have the user type again and confirm twice Which is not the most convenient thing, but it works So the alternative options you can think of or at least I can think of our worst And typically if I want a user to if I want to use it to verify that the trusted UI is genuine You would have to train your users to try to take screenshots for example and see that they can't take screenshots So that's not something is very realistic. I mean geeks can probably do that but not the regular user and So far is windows only so if you want to run those tests you can't run them online X That will probably change over time as well We are still so one part. We're still missing compared to 2017 is a security audit And that's what we will be focusing on right now And that's the reason why typically I didn't update the code because we didn't run our security audit yet So on the first part of the security audit, you want to run that like a standard security audit So you want to verify that your own clave is not vulnerable to typical bugs Buffer overflows and so on so that's very very normal Then you want to verify something more You want to see if your key can withstand several side-channel attacks Because side-channel attacks got very popular during last year So more and more people have been able to have been demonstrating Ways to extract keys from enclaves either by attacking the enclave from another one or from the host and Today there is still a state of the art to be written to know if keys are correctly protected in an enclave And we are into we are very interested to answer this question We are very interested to publish result and we want to advance the state of the art of protecting key and enclave so Good news is that we are I think good at it At least we already did it on hardware so we should be able to do it and bigger hardware as well as an enclave and That just a random advertisement, which is not totally related to side-channel on a cache But it's a general side-channel API that we published a few days ago that will let you test on State of the art state channel on templating So how can we how will we proceed with this audit? So first we'll focus on a single curve. We'll focus on sake p256k one Which is a curved used by a lot of cryptos today. So at least Bitcoin and Ethereum So for the time being that the curve we are the most interested in We will review the state of the art library used today by multiple project Coming from Bitcoin core. So leap sake p256k one and We will test it against state of the art side-channel attacks that we have on sgx We will publish a report a review on that a detailed report if there are patches to be written We will do that as well if we have some well parts to rewrite We will also do that and in the end we want to know if and when how long we can store keys on sgx and I think that using this research We will be able to finally have a workable on clay a workable hardware wallet on an enclave and with strong guarantees that the keys are going to be Available and that the keys are not going to be stolen for a given amount of time So for this we chose not to use the Intel proprietary cryptographic library Because we figure that working on an open source code and providing some providing some review of that Will benefit more to the community by knowing how we can how we can work and Design new side-channel protection attacks which could later be applied to other curves So to finish summary of what is coming next in 2019 for enclave First we want to start with the CTF. So after a review we will test so we will publish what we did with our hardened API and Well standard CTF. So if you win you get better because well, we'll put some ads In our enclave. So we will usually increase the amount and we'll see if people are interested in if people manage to extract something That worked for our cryptographic API on our hardware wallet. So that worked on Well two bitcoins I think on one bit coin. Nobody steal it. Nobody stole it on two bitcoins We found some motivated parties. So maybe we'll see the same here After we do that and we're convinced that our security is fine Then we can we will be able to release a wallet So we will release a simple wallet that will work first for Bitcoin and Ethereum and then we can move forward And release an SDK that will let people write their own applications and use PTD to secure their own applications so that's it and We still have some minutes for questions if you want