The case against using TEEs in your crypto project

Transcript

hi okay hello my name is Mario he's got a and we're here to talk about the case against using these in your crypto project we work at the stamp relapse and for a little bit of context we've been building with it for the last years which is a decentralized oracle network so the question is like why are we here I think it's pretty obvious but let's say it so because privacy it's important at least most of the public block chains obviously smart contracts are deployed and cold publicly it means everything is it's available for anyone to watch it to

twist new pin and we cannot use obviously private inputs there are many graphic workarounds the half in there for several years like sickest narcs or a morphic encryption but we are here about to talk about the t's the promise of a perfect solution solution so after explained a little with the t's we'll go continue defining or showcasing some hardware attacks then we plan to have a demo of a Spectre but fortunately it doesn't work in Linux and we will finish the presentation with some use cases in the crypto space and some conclusions so the promise of a perfect solution so T stands for trusted

execution environments which are simply a secure area in the hardware that aims to provide confidentiality it means having encrypted and also integrity trying to to avoid that anyone can tamper with the data so it's really important to say like these areas in the hardware are really isolated from the non trusted world such as applications or operating system and they have different names depending on the manufacturer the ability in the case of a a mistress on this were one of the first ones and we also have Intel's with se X well-known an EMD secured processor so a

one of the things that these provide is encrypted isolated memory in the case of Intel it is called enclaved page cache which is just a specific part of the RAM memory that is being encrypted with a hardware key it's been using the well-known eyes encryption and the idea is like in the memory and in the memory bus in the RAM memory a memory bus any attacker can release new pin because it's encrypted and obviously he cannot really see what the flow of a of the data what the data is in transit and this boundary finish in the CPU so maybe we have a Rivia a hint like maybe an attacker will try to

use these after the CPU so another thing that are really important for at ease are the attestations first the local ones this is just to two different applications to prove themselves to prove one to another that they are running on the same platform the flow is really simple it's based on our challenge response simple protocol that the one in clave sends a request to the in cliff to application our that is running an and cliff a and in cliff as the hardware to sign to produce a report that contains own information about the build some locks of the enclaves how it was built and how it was initialized and

it's time by a symmetric key provided by the hard work later on it's sent back to to the anklet beam and it can also ask the hardware to verify those report then the next one is the remote attestation is similar but here it's using a special anklet called a cold cotton in clave in the case of Intel in this case the sand clay fused and a symmetric key and as its issued by Intel it's called a a PID key and the flow is is similar in the way like this a challenge response imagine we have a challenger that is outside of a platform and it wants to verify that some a application cliff is running in a specific hardware

for that he sends a request nursing way the application forwarded to application in clave then in the point to what we have is the local attestation so then cliff a application and clave and the protein and clave they have to prove that it's running on the same platform and if it's the case then the cotton and clave will sign this report using this Intel key which is in this case and symmetric and it will be forward back to the Challenger so once the Challenger receives is a report a either he knows some public key to verify this report or maybe he could also ask requests third-party service from Intel for

example to verify that this report is correct and valid the other things like with this what we can do is like we have a communication from the outside world imagine we are very generating a symmetric keys within an enclosed like an external client could send a data through an untrusted channel and an untrusted operating system using this a symmetric key so it opens from many use cases that can be can be can be used so now the interesting part is the harvest axe before starting so why they that is why this enclave's the idea is really

basic and it's just to decrease me the attack surface of of an application so normally without enclave's we know that malicious user may maybe me try to exploit the operating system or the virtual machine manager find the case within claims we this surface act a area is reduced to a portion of the hardware and the application layer so going straight to a point so what are side channel attacks these attacks are those in which a malicious user try to use a covert channel physical try to analyze some physical behavior in order to extract some

information ladies some examples are trying to analyze for example the power consumption the magnetic waves some acoustic for example some noise that the harbour is doing or perhaps the exception time some some algorithms or some code or even determine ladies like to gather information that may seem as noise at the very beginning but then they can try to infer some confidential data that is it's ongoing in the code so this for example is a famous case that is the threshold one that suffer one of these attacks here they take aways like dual side channels really always need physical access so doing this

presentation will showcase that not really and this is the start of our concerns so in a in a context in which we have a material architecture like Forex mode this one from Intel and attacker may try to exploit or to infer information from the different of the components and the sad reality is like many years most of the manufacturers they have been focusing on trying to make their architectures more efficient but disregarding some security concerns this all of us we know they race their walls with a CPUs for example between Intel AMD but anyway that's what happened and now the open some

vulnerabilities to be exploited and this is also applicable in some other contexts like for example imagine a cloud in which you are sharing some hardware or even a smartphone or in the case of this presentation they trusted execution environments so I leave the floor alright thanks my yep so that was there was a very nice introduction and how like how can we or we saw some micro architecture components that could be exploited actually actually shared between the t's and the normal processes that are hosted in an operating system so let's go one by one to see what can

be exploited and what can not all right so the first one that we're going to kashish all right so basic caches are just small pieces of memory that I put between RAM and CPU so that you can access data faster right so basically the whole recently accessed data so that you can access to that data first usually we have a multi-level here key that means that usually we have some caches that are some cache levels that are private per core and then we have like a shared one at least the last level one which usually shared across course and also some interesting things that the first level you should is divided into the data cache and instruction cache that means that the data cache essentially holds data one

instruction holds instruction I did this yesterday as well so how this how do we decide or how does the CPU decide where to which location does a an address go right so it's address by the physical the physical address so we take the physical address and part of it we use it to select word to the cache that piece of memory goes right so there's usually caches are divided into sets we can think of them as buckets so basically the physical address one portion of the physical is decides which said that that memory goes so with let's go to how one can how how an attacker

can infer information from from the cache so essentially for the record let's try to let's try to assume that the attacker and the victim share some kind of memory and although this might sound a bit strange that's usually the case when we launched like two processes in the same operating system with with something that is called kernel sure same pitch memory so it's not that that data Xchange so essentially if we assume that the tiger and victim are shown in the same the same memory pieces but what we when I used to do this attacks what we used to do is just take the entire instruction set architecture definition and look for like nice instructions and one of them from Intel was skill flash

right so CL flash what it does is it takes a memory address and flashes it from the cache hierarchy that means that if again the attacker shares the memory piece with a victim that can just make sure before the victim executes its code that the memory piece he wants to monitor is out of the cache and then if the victim actually utilizes it or not if you do till Isis it it will actually load the data into the cache and the attacker what it's gonna do is measure the time it takes to access that location that name of it this since he has access to it and they what he's gonna see is that the cache accesses are around a hundred cycles faster than Ram that means that he can infer whether the

victim utilized that memory please remand how do we measure those hundred cycles it's usually Hardware whole providers put some registers there so that you can count cycles great that was very nice but they shared memory assumption sometimes doesn't hold and sometimes we want to attack something that is not shared with the victim so how do we do this well essentially the attack is very similar but this time what we're gonna do is assuming that we know to which set the instruction for instance that we wanna monitor goes into the cache what we feel is that set we trash the data he represented with the green memory blocks and then we just let the victim access his instruction that

we want monitor not if the victim accesses it of course since the set was full the victim is gonna throw away one of our trash addresses from the cache and that means that when we when we measure the time to reload those our trash addresses three of them will come from the cache on we can measure it and one of them will come from the memory from which we can infer that the victim utilized the instruction we want to monitor yeah so how does this translate to an to an actual attack so this is the algorithm that was implemented for I say in new PG not that much how all like five years ago and if you can see I mean the important thing

to notice from here is the fact that it goes it takes the secret and the secret key and it goes bit by bit if the visitor cereal only ask where is implement is executed and it the one a square plus a multiply is is executed that means that essentially we call this a secret dependent execution because it depends the execution of the program it depends on the secret that you so in imagine that we can with a previous attack or any with any of the previous attacks imagine we want to monitor this instruction or this one right in this case the graph shows the monitoring session of this instruction and what we see is that when when the bits of one of course we see more time

between these two squares right so basically this the utilization of this one basically depends or the time between executions of this instruction depends whether on whether the bit is a serial 1 so we can reconstruct the entire key like this great that was those four caches so caches are attackable what else is that there's something very cool in the CPU which is called branch prediction unit it's essentially a piece of hardware that tries to predict the branches that you have in your code so tries to predict the outcome of the ranch's you have in your code and yeah they're not that different from caches in the sense that they are finite finite in size and so basically the the way to attack it is very similar as well so

branches have a specific position usually in branch prediction units so if we know the branch we want to attack in this case imagine the same one as we had before it on RSA so what we do is a couple of things we first need to understand the branch prediction unit how it works right so for instance there were many branch prediction units in the past that predicted the if the branch wasn't in that buffer that holds the predicted the predictions actually the branch was predicted has not taken all right and it wasn't inserted in that in that buffer until it was Miss predicted so as long as it was predicting it well it wasn't it wasn't actually adding it into the buffer so taking those two

things in mind so what we can do is have a trash branch always calling it always taking it so we have our own branch that goes into the same position as they as the target branch that we want to monitor we always take it alright so what's going to happen if their bit if the victim uses that branch what it's going to do it's it's going to kick out our ranch from the ranch prediction unit and the next time we we call our branch what we will see some it's prediction why because it is predict that's not taken because it's not in the buffer so we can measure that and that is gonna force CPU road back or so a pebble in robot and yeah that that's measurable and that that leaves like a twenty cycle difference between one and the other so

with those two things we can understand very well they to those two things and the one I'm gonna explain we can just and very well what happened with the specter and and meltdown attacks that were actually very famous so yeah what happens when when a branch for instance is predicted as taking or not taking what's gonna happen is that the CPU as we said is going to execute the instructions that follow that branch yeah expect speculatively so basically it's going to execute instructions without knowing truly whether it did it needs them or not all right and then of course if the branch was predicted wrong the that pipeline execution has to be flushed so but that

was the branch was just an example there are many other cases in which that happens we will see it later but the branch is the one the branch of speculative instructions the one that the Spector spectra attacked so how does the spectra that work it's pretty easy understanding the caches on the branches so we first have let's imagine that we have in our victim code a branch that looks like that alright so we have a branch in which we can insert let's assume that X is controlled by the attacker so basically X is an input to the code we want to attack for instance and we have a typical buffer overflow control measure which is if you want to access an array first of all check that

the input actually fits the array so yeah what what the attacker can do is essentially call that instruction like quite a few times with the right X length or size so that that that array is actually always taken all right so basically I trained that that that that branch so that so has to be taken all the time and then suddenly when I know that the predictor knows that branch should be taken I just changed the X so to insert an X that it's bigger in size and the array that we want to access so what's going to happen in that case in that case the the branch is going to be predicted as taking as it was set by the

branch prediction unit and that instruction the second one is maybe speculatively executed so basically it's going to access and a memory a memory location that we should have access to and that obviously leaves traces in the cache and if we monitor the cache to see that instruction happening before it's rolled back we actually can access locations again that we shouldn't have access to mail down was very similar to a specter but it exploited another kind of a speculative execution which is when you try to access a foreign region so a region that you don't have access to literally just put in an address that

you don't have access to the CPU before checking whether you have permission to access that that memory piece it actually loads a memory piece so it loads a memory piece or it loaded the memory piece and then check the inside a weather you have permission to actually access of course if you didn't have access it it rolls back but by that time you you you can already see the effects on the cache and that means that you can actually dump the entire memory of another processor including a process running in the team so yeah couple more attacks so we saw how speculative execution can be attacked how caches can be attack how branch prediction units can be attacked this

time we're going to see how pork on pork ports can be attack so essentially ports are just poor thing to which we corporations are are sent so basically your your your computer is turns into real computer sorry your software is translated into micro operations and then it's sent to an scheduler that those instructions in two different ports um but there are the problem is that this balance in the scheduler doesn't balance not a scalar it per se but some ports have specific instructions that can only be executed in that port so that means that if we find a secret dependent software or if we're running a secret dependent software again that uses one of the ports depending on whether the secret is a or b we again can generate contention

on the port so as to see whether the victim is actually utilized in the portal again measurable in time and again potentially living to full security structure a leakage and then the last attack that we wanted to cover here is are a bit different they're called fault attacks they are not side-channel attacks and we haven't seen many in HDX to be or or any T to be to be honest but recently there was a paper that actually up yeah executed one of this in a very funny way so um yeah fault attacks are just attacks in which we just induce an error in in the execution of an instruction it can be because like you know we increase the

voltage so much that it leads to an error or whatnot alright and that can if you're running something like a yes that can lead to the key extraction why so if we have the same plaintext and we got one of the cipher texts and we had we got one faulty ciphertext due to some external attack that we have made we can execute fault analysis and that's that gives us the key so um the attack I mentioned that was proposed in the CX was called plunder world it's it's quite recent so I encourage you to read it so up it actually yeah there's a very funny

register to which if you have kernel access which is assumed by the attacker model of off of HDX for instance you can actually touch a register that is called yeah it's the MS early history and remember put the in Stanford but yep so essentially that lately that actually allows you to change voltage of some components by minus 1 or plus 1 volt so um yeah an attacker essentially it's it's been the following an attacker learns about how or a tweet voltage at which voltage this if the CPU fault and when someone for instance the victim issues in AES and I for instance attacker sends that voltage before completing the encryption and he gets

the faulty ciphertext again this wouldn't be a problem but that the the fact that you know some like we can see the results it results that most significant bits are flip which is actually something quite predictable or else like one to five continues bits are flipped and yeah we had a demo it's a pity that we cannot show it because obviously in Stallions TX I don't know if someone has Intel SGX drivers in his computer but you guys know it's if you have it's it's a pain in the ass so I had it installed in my computer but it doesn't work because it's a link from here so I I can show it later if someone wants to to to show to see it but yeah it's a pity that we had to skip this

actually Somalia whilst speak now oh sorry Moreno will just pick up some use cases okay so let's continue with some use cases and they keep the space that time to show some of us already know them so the first one is about confidentiality the the idea here is like if we can create an a symmetric key in a key a nutty for example obviously we could use this in our benefit in order to send for example to a smart contracts on private inputs that only did he can decrypt the tip example I hate is the flight insurance mark on dragon which for example Alice wants to

cash out some insurance money and she doesn't want to disclose which flight she was going to take so for that she encrypts the data with a symmetric key that lives in the with nate'd and obviously it is the only one that can decrypt it then it will do the the query to the API in a secure way for example using TLS we know some products I do that and then the result can be in plain text I mean without the you know cypher text and then she can make a shout so here the problem has work said it's like we don't

know for sure if there could be some side channels attacks that may infer some information that isn't transit so and the the same some fault for key fault attacks may also lead to some key extraction that will invalidate continue in the complete scheme so the other use case could be for key management we know these are a piece of hardware we know hardware can generate random numbers with much better guarantees and software so why not use that in order to generate for example some cryptographic keys imagine we can interact maybe we can generate some passwords in the tea that are from other block chains

in that way we could use using our credentials in some blockchain we could interact or sign transactions towards other block chains here is the same if we cannot be sure that they could be some attack they I mean if we if they could be some attacks such as such an attack sanity may be is from random not the random number can be inferred in some way really a endangering all the all the fans know in this case in the case I mentioned and the last one is a is similar to a previous one because it's also realized on the hardware random number generator and it is like to use it as public becomes we know

there are many platforms or systems they would like to have some sort of a committee selection being done in some random way and for that is a really nice use case here the impact of the attack is less not so high but obviously a fault attack may reduce the interrupt maybe they could with some prediction or you can decrease the you can predict which a random numbers are more a proble or not okay to finish some takeaways obviously did in the last years we've

been we have seen that they are increasing number of attacks on hardware so that doesn't make us sleep well to be honest we know T's they are not the perfect solution as it seems not because they are not great but because they are not for example they don't make us code better and maybe they have not been been fully updated so maybe here's a food for thought for manufacturers maybe they could in the future I don't know if we will do think about some design having more security concerns in mind however we know these may be super nice for some

use cases but one size does not fit all they would part of all as always is like because some of these security concerns they are super nice cryptography protocols that have appeared in the last years like they Co Mexicans yep and just to finish as I mentioned before we come from with net we are building up this entire circle network many times we're asked why we don't use these and here the answer is really clear because it's a we really don't don't need it in the sense like we're building a center I struggle network that is completely translates

is permissionless and our security model is based more in cryptography sortition it means having a high number of nodes that will be assigned randomly to execute some tasks we can understand this better with a diagram this is the lifecycle of a data request within with net the first stage is the data requests definition how data should be queried I gated and they tallied it means converting it from several reporters into one single data point the next one is the commit phase in which all the nodes from the network they will compute by themselves if they are eligible to perform to execute this task and they

will do it using PRF but if I were a random function that has an input also the reputation they have so the more honest they behaved in the past the more odds they will have to execute to be assigned to a task then they will follow a Community Builder scheme is yes sending a commitment and then sending a real transaction with a result and finally once we have the results from other reporters there will be a another transaction in the next block that is the tally in which in this case a miner takes all the results from other reporters applies a deterministic function that reduce and aggregates the results into one single data point that's all thank you very much for

listening if I took your interest in something about Oracle's we have tomorrow to work out about radon which is a domain specific language for Oracle's so thank you very much question yep yeah thank you for the presentation so given that we can expect a lot of notes in whatever decentralized network we have are actually running on shared execution environments in like virtual

machines for example on AWS or DCP isn't something like trusted execution environments like STX still raising the bar so to say like it's not an impenetrable fortress but you're still when used as like a layer defense strategy it's still racing the walls for penetration so I would argue that it if you have the possibility should still use it not as an alternative to something else but as a complementary in security that's that's a very nice you know thinking line of thinking I tend to disagree but basically because like when you assume that you're executing for

instance two virtual machines in the same hardware do you assume that the I mean you assume that the virtual machine manager very interesting the operating system is not gonna be malicious that that that it's it's much harder to talk so when you don't have control on how tasks are scheduled to the big team process in this case an attacker process that's that's a very hard let's say a scenario in which we can attack I mean it is at a couple still but probably the number of traces that you would need to infer a key is much higher in the tease that changes so if in a team I'm assuming that there's some malicious guy that is suffering some kind of isolated Hardware piece that not even that malicious guy can tamper with so since he's in control on how things are

scheduled in that case it allows for like much finer much fine grain attacks which essentially with one or two executions you can you can get I'm guessing like not a so defense to the hypervisor but two neighboring VMs for example yeah sure in that case we were yeah I mean we're not like against T's in all the scenarios but there's there's some scenarios in which if the person you're especially if the person you're utilizing the the T for like it's is entrusted like it's not the case in this case in a ws for instance but if I if I have a decentralized protocol that I'm trusting like just random people I

don't know that are offering their their you know tea is to execute the stuff in that case I I think it's quite quite dangerous any more questions all right thank you so much for attending [Applause] you