 All right, thanks for the introduction. And this would be a blockchain-less talk. So the title of my talk is Attestation as a Service, all which neatly abbreviates to S. But before we go into technical details about security of trusted execution environments and attestation protocols, let's start with some basic philosophy. So if a tree falls in the forest and there is no one around to hear it, does it make a sound? Does it even matter? Do we care? Well, I would hope that the owner of this car actually cared that the tree fell on it. But it depends on context, right? This tree actually made a sound when it fell. I hope so, at least. OK, so now that we've graduated basic philosophy class, let's talk about security. If a machine was hacked somewhere in the darkness in someone's basement and there is no user data on it, does it matter? Should we care? Well, again, it depends on context. Because every SGX capable machine can actually access a prized asset, an SGX private key, also known as EPID key. But never fear Intel has assured us that these keys are carefully guarded and one simply cannot access an SGX key easily. And these keys show never you leave the confinements of Intel CPUs. Well, some things even Intel cannot protect against. And you might have heard last week at Usenix we presented Forshadow. Forshadow is a speculative execution attack against Intel hardware. It breaks protections and security boundaries enforced by virtual memory. It has applications to virtual machines. And one virtual machine on the cloud can read another virtual machine on the cloud. But it also has implications on SGX. It can basically dump any data located in SGX address space. And we can roughly dump 100% of the data 100% of the time up to measurement errors. And in case you're all wondering how does this seem in practice and how hard is it to do, well, let's start with the demo. I've initialized here an SGX enclave. I've hid a super secret string at this address. I can dump the entire memory space. But it's much easier to analyze demos when you know where the interesting data is. So it's in this address. And when I try to simply read it and simply access it, I get 0xff, which is SGX protection mechanism, also known as a page semantics, because one cannot simply just access SGX memory outside the context of SGX. That's how it was designed. That's what it does. But when we try speculative execution, and most specifically for shadow, this is what happened. And this is our super secret text taken from Intel Security First pledge. Well, they'll happily tell you that Intel Security has been one of the highest priorities in the four years of building security for every product they create. Well, that's a combination of a licky micro architecture and speculative execution. That's what happens. Ah, and we even have a measurement error, so you see that I did it live and I wasn't lying. OK, but now that we have the capability of dumping SGX memory, what do we do with this? Why is this useful? Well, we can go ahead and use this capability to steal EPID private keys, which are located inside every SGX-capable machine. But what are the security implications of somebody getting his hands on an EPID key? Well, to do that, I have to bore you a bit with SGX attestation. So we have a usual delegation scenario. We have the client, we have the cloud. The client would like to delegate some computation to the cloud. And the cloud would like to prove to the client that it is running genuine SGX hardware. So how do we do that? Every SGX machine has a key inside it. And the client, the cloud takes the computation, give into it by the client, hashes it, and then uses special SGX instructions to sign it, producing what's known as an attestation quote. That quote actually acts as a proof that this computation is being run on a genuine SGX machine. This quote is given by the cloud to the client, who cannot verify it by itself, but he takes it to the Intel attestation server, which gives us back a OK. And together with the client and send his session key, we establish a joint key, and then the client can communicate to the enclave running on the cloud, securely, with this command-derived secret. Now, the key taker, a message of this entire slide is that the security of this entire attestation protocol is based upon the fact that nobody can access an SGX private key, except genuine Intel hardware under some conditions using SGX instructions. OK, well, we got our SGX key, but so what can we do with it? Well, to do, to understand that, I need to dig even deeper into the SGX enhanced privacy ID group signature. It's a group signature, and it has an epic feature, privacy. It's unlinkable, which means that nobody can tell who signed what and how, and you cannot link a signature to its public key or to the identity of the signing, which basically means that if we have this red guy here that signs something, nobody can distinguish between it and its surroundings, and nobody knows who signed what. Unfortunately, with enhanced privacy comes enhanced responsibility, because even a single extracted EPID key can be used to forge signatures for millions of machines without anybody being able to distinguish between signatures made by the attacker and genuine signatures made by SGX machines, which basically means that one compromised key erodes trust in the entire SGX ecosystem. Well, to help facilitate that erosion of trust, we'll give you ass attestation as a service. It's a Twitter bot that would attest to anything you tweet at it. It's reduced the cost of the attack, since you don't know what you need to own an SGX machine. We'll need it for you, and we extracted the key, and we put it available online for public service. Your identity is protected by the privacy of the EPID protocol, because nobody can say who signed with what key. Currently, it returns group out of date because Intel had issued a patch against original foreshadow, which means that we need to update our machines, which we haven't done yet. So if you take out the stations to Intel's server, you get a group out of date, meaning we have to update. Unfortunately, or perhaps not surprisingly, despite weeks of advance notice, the keys are still not revoked. So these keys are still out there, but unfortunately, I just heard 10 minutes ago, we got blocked by Twitter because they're worried about the security implications of this entire business again. And if you cannot rely on Intel to revoke SGX keys, well, at least I hope you can rely on Twitter to defend the security of SGX.