 All right, so the next talk here will be cash quote, efficiently recovering long-term secrets of SGX, EPID via cash attacks. This is work by Fergus Dahl, Gabriel de Miquelgui, Thomas Eisenbarth, Daniel Gankin, Nadia Hanginger, Ahmed Moghami, Yuval Yaram, and it will be presented by Gabriel. OK, thank you for the introduction. So first, let me present this paper. So cash quote, efficiently recovering long-term secrets of SGX, EPID via cash attacks. So I will give you a bit of background about Intel's software guard extensions to start with. So SGX is this security technology that was introduced by Intel in 2015. And it's basically just a set of extensions of Intel's X86 architecture. And SGX allows users to perform secure computation on potentially compromised platforms where an attacker controls everything, including the operating system. So in order to do this, SGX introduces this new technology, this new environment, which are called enclaves. And these enclaves are isolated from the rest of the software. And SGX is going to control the access to these enclaves in such a way that even the operating system, which could be malicious, do not have access to the content in the enclave, so the code and the data in the enclave. So now we are in the situation where we want to put the enclave on the cloud. And we have the following setup where we have an Intel SGX machine on the cloud, and we have a client. And the client wants to make sure that it is communicating with, first of all, an enclave, which is correctly initialized, and most importantly, with an enclave, which is running some genuine SGX hardware. And to do so, SGX introduces this remote attestation protocol, which is called EPID, and hence, PrivacyID. And so the cloud is going to want to prove to the client that it is this genuine SGX machine. And to do so, the proof here is going to be this cryptographic signature, which is going to certify the enclave's content. So first of all, every SGX machine has this EPID key, which is given to it by Intel. And when launching an enclave, the cloud is going to use some special SGX instructions, along with this EPID key, to hash and sign the enclave's content. And this hash and signature is what we call this attestation quote, which is then sent to the client. Now, the client sends this attestation quote to Intel's attestation service for verification. And if Intel is fine with the quote, it says, OK, this is a fine quote, then the client can communicate securely with the enclave using this fmrl key that has been joined to the quote. Now, there's various important things to notice about this slide. First of all, the whole trust of this protocol is based on this EPID key. The client can be assured that it is communicating with a genuine SGX machine, because only these SGX machines have access to this EPID key, this attestation key that is given to it by Intel, and can then use these special sets of instructions to produce the attestation quote. Now, when the client receives the quote, it has to send it to Intel's attestation service. And one of the reasons why Intel has this attestation service is because of revocation. Intel wants to be able to revoke platforms whose signatures or keys have been compromised. Now, another reason why the client cannot verify the quote itself is because Intel or SGX in particular is going to encrypt these attestation quotes. So the client cannot verify it itself and, again, has to send it to Intel's attestation service. Now, if we're in a scenario where Intel is malicious, then this brings up a privacy issue, because this attestation service basically has access to all this information, which the client is communicating with which enclave. That's a lot of information. And so in order to remedy to this privacy problem issue, SGX implements this security guarantee, which is called unlinkability. And unlinkability basically tells you that it is impossible to identify a platform that produced some signature on some message M. So if the attestation service receives this quote from this red processor, this is basically undistinguishable from any other quotes produced by any other processor. Another security guarantee that SGX has is this unforgeability, so it's impossible for an attacker to forge a valid signature on some message if it does not know the secret key. So now, in our work, we give a cache attack on Intel's EPID protocol, which is implemented inside SGX. And using this cache attack, we were able to recover part of the enclave's long-term secret key. And if we have part of this secret key, then a malicious attestation server, such as Intel, can break this unlinkability guarantee that I just mentioned. So now, in order to explain to you how this attack actually works, I'll just give a little bit of background on EPID. So EPID has four entities, basically. It has an issuer, a revocation manager, a platform, and a verifier, which in our case, the verifier is going to be Intel. And we have the following algorithms. So first of all, we have the setup algorithm. So the issuer here is like a group manager. It's going to decide who joins the group or not. And on some input 1k, where k is just a security parameter, the issuer is going to use the setup algorithm to output a pair of keys, a group public key, and an issuer secret key. Now, a platform wants to join the group. And so it performs this join protocol, along with the issuer, where the issuer has its pair of keys as input. The platform uses the group public key. And then the platform learns a secret key, SK. The secret key is private and unique per platform. Now, if the platform wants to sign a message M using the secret key SK, it produces a signature that it sends to the client. And then the client sends it to the verifier, so Intel in this case. And finally, if we want to verify a signature, Intel verifies it for us, basically, and tells us if the signature is valid or not. So in our work, we look in particular at the signing algorithm, which is in this EPID protocol. So remember that at the end of this join protocol, the platform learned a secret key SK. And the secret key is composed of some element F, which is taken from a group ZP for some prime P, and some Intel signature on F. So Intel uses this BBS plus signature scheme, which does not really matter for the attack here. Part of the group public key, we have a cyclic group G. And from the cyclic group G, the platform defines or chooses a basis B, and then computes a value K, which is equal to B to the F, where F is, again, part of the secret key. Now, how do we sign, or how does the platform sign? So remember that we have this unlinkability guarantee, where we want to make sure that from a given signature, we're not able to retrace our way back to the platform. So in order to sign, the platform uses a non-interactive zero-knowledge proof of knowledge, where the proof or the statement that the platform has is the platform knows some unrevoked F, such that the F satisfies the following equation, so K equals BF. Now along in the protocol, we require computing this exponentiation. So we have some value A, and we raise this value to R, where R is a nonce, again, a random element chosen from the group ZP. At the end of the signing protocol, we output a signature. The signature has the values K and B in it, so K and B are public. And it also has this value S, which is going to be equal to R plus H times F. R, again, is the exponent in the line above, so the nonce that we have. H is the hash of some public values, and F is part of the secret key. So now, what's the idea behind the attack? So we want to get information about the length of the nonce R in this exponentiation, and this can be done throughout a side channel attack. Now, if we're able to get a lot of information about these lengths of the nonce R, so we have many observation, we can use this information to mount a lattice attack, and this lattice attack will allow us to recover the secret or F, the value F here, which is part of the secret key. And if an attacker recovers F, then it breaks the unlinkability guarantee. So more precisely, how is this unlinkability broken? So remember that the secret key F is unique for platform and private. Now, the attacker knows a signature sigma, and then, using this side channel attack, managed to recover F. So if the attacker knows F since K and B are public, then the attacker can verify whether K equals B to the F. And so if we have a list of signatures, and we can verify whether K equals BF for each signature, then we know which of these signatures was actually signed by the given platform. So this breaks the unlinkability guarantee. So now, let us go back to the first step of the attack. So we want to have this side channel information about the length of the nonce R. And to do so, I'll give a little bit of background about cache attacks. So we know we have this gap between the speed of a processor and the memory latency. And this results in the fact that if a processor wants to access some data from memory, then it has to wait. And if the processor wants to access memory again, the same data, then it has to wait again. And so this means that all the speed that we have in the processor is kind of counterbalanced by the fact that we just wait for memory. So to bridge this gap, processor designers introduce this small memory bank, which is called the cache. It's located between the memory and the processor. It's closer to the execution core, and it also runs with more expensive technology. So the cache is going to divide the memory into memory line, and when the processor wants to access some data, the cache is gonna bring the data to the processor and also store a copy of this data in the cache. And when the processor wants to access this data again, it accesses directly from the cache, which is a much faster access. And this behavior is exploited in an attack which is called the prime and probe attack. So we have the following setup. We have a spy and a victim, and the spy wants to learn information about the victim's memory access. So first of all, the spy is gonna allocate a cache-size memory buffer, and then the spy is gonna prime the caches. It accesses every single memory line in the buffer, bringing the memory lines to the cache, and so the cache is filled up. And now the spy waits. The spy waits for the victim to execute some code, and when executing some code, the victim brings some instructions to memory. Now, since the cache is full, it has to evict some of the spiced data in one of the cache sets. So the victim stops waiting, and then the victim is gonna probe the cache, and it's gonna measure the time it takes to access every single cache sets. If the access is fast, that means that the spy is accessing directly from the cache. If the access is slow, that means that the spy is accessing the main memory, which means that the specific cache that he's looking at has been accessed by the victim. So if we repeat this prime and probe cycle over time, the spy is able to learn the cache access behavior of the victim. So now going back to our attack. Remember that in the signing algorithm, we required computing this exponentiation A to the R. Now the exponentiation is using some sort of variant of the square and multiply algorithm with a fixed window length. Another information to know is that in the coding enclave where the signing algorithm takes place, the nonce R is gonna be recoded with a fixed window length of size five. So now if we look at the square and multiply, sorry, the scalar multiplication algorithm, so this variant of square and multiply, this algorithm is going to look at the recoded representation of the nonce R from the most significant bit to the least significant bit. For every single digit, it is going to perform W's querying operations followed up by a single multiplication, and here W is equal to five, it's the window size. So now an important thing to notice here is that everything in the while loop is constant time. However, this algorithm is going to leak information about the number of iterations that is performed in this algorithm. So if we have a scalar of length 256, for example, the recoded representation of this scalar is going to have 52 digits, again, because we're using a window of size five, and this means that this main loop is going to iterate 51 times. Now if bits 256 and 255 of our scalar are equal to zero, the recoded representation of our scalar is only going to be of length 51, and so this loop is going to iterate only 50 times, and if we continue like this, every time we have a chunk of five bits equal to zero, the recoded representation of our nonce has one less digit, and so the loop iterates one less time. And basically if we are able to count the number of iterations in this loop of this algorithm, this gives us information about the length of the recoded nonce, which then gives us information about the most significant bits or the number of zeros in our scalar, which is the kind of information we're interested in. So counting loops, this is using this prime and probe attack that I explained before. So we're monitoring cache access patterns during the computation of this algorithm. We obtain traces of this form. So basically we have a constant pattern that is separated by peaks. Constant pattern basically corresponds to iterations in our algorithm, and counting the peaks in this trace will allow us to get information about the number of iterations we have in our algorithm. So we obtain traces of this form. This is just an example. Here if we look at the blue part, we can count 48 traces. 48 peaks, sorry. And this means that our algorithm has 48 computed, I mean, executed 48 iterations. So now we have used this side channel attack to get information about the length of the nonce R. And we wanna use this information in a lattice attack to recover F. So the goal in the end is to get the secret key. So remember that we have this, at the end of the signing protocol, we have this quantity S, which was equal to R plus H times F. Again, H was the hash of some public values, F is part of our secret key. Now, throughout side channel information, we get all these samples SH that satisfy this equality. And if we reorder a little bit the terms of this equation, we have S minus HF, which is equal to R. Now R is our nonce, and we have information about the number of most significant zero bits in this nonce. This is what we got from the side channel attack. So since R has a lot of leading zeros, or we know how many leading zero it has, it's small. And so the length of R is actually upper bounded by P, which is the prime, divided by two to the L. Again, two to the L is the number of leading zeros. So we have S minus H times F in absolute value, which is smaller than P to the two to the L, divided by two to the L, sorry. And so this is exactly the setup that we have if we wanna use the hidden number problem. So the hidden number problem is this algorithm, which allows us to recover some secret under some assumption in polynomial time with some probability greater than one half. And this equation gives us, this inequality, sorry, gives us the assumption that we need to use this algorithm. And so the hidden number problem using lattices is what we will use to recover F, which is the secret we wanna learn. So now in our experiments, we have a few numbers that I can show you. So basically it required approximately a little less than 8,000 signatures to recover the full key. So it is possible to use some trade-offs in order to reduce the sampling time. This is all explained in the paper. I don't have a lot of time here to talk about this, but basically we can use loops of different lengths in order to reduce the sampling sizes. Some signatures are easier to find than others. And in the end, adding some manual inspection to this, a little less than 7,500 signatures were required to recover the full key. So finally we're happy. We have F or an attacker has F. Now, as I mentioned in the beginning, this attack has some limitations because Intel encrypts the attestation quotes. So there's no way for a client to decrypt these attestation quotes. So this attack can only be run by Intel because everything's encrypted. So a malicious Intel, though, can break the unlinkability guarantee of this protocol, which is still interesting. Thank you. Thank you very much. So I think we'll have time just for a question or two if there's any. If not, I had a quick question. So I'm not very familiar with the SGX. Where's this found? Is this in all sort of Intel products or what's the applicability? Yeah, SGX is found in most Intel product, I believe. Was that your question? Yeah, no, that's, I just wasn't familiar with it, sorry. In the meantime, question, yep. Your product uses a windowing method. Have you also looked into whether the Prime and Probe attack is also capable of seeing which one of the pre-computed values is accessed? So you could recover the key directly? I don't think so. I mean, we haven't looked at this, but yeah, we haven't looked at this, so I'm sorry. A follow-up question, actually. I had quickly, how much information was available on the, like how much did you have to reverse engineer of the firmware or anything like that, or was there public information on the algorithm? The code is public, SGX code is public, so we can look at it and use it in decoding mode to, for example, the reason why we were able to run the attack is because we can look at the code, change the public key, you know, and so actually run the attack. Otherwise, we couldn't, as I just mentioned, but no. Perfect, any other questions from the audience? If not, thank you very much. I'd like to speak again. And there are a lot of free seats in the front here, so at least as many people as I see standing could be sitting. If not, we'll force everyone to do a defrag, and it's much easier to just sit in the front here. But with that, we'll switch.