All right. I will go ahead and get started. I'm going to try to do this in about 15 minutes
so that we've got plenty of time for questions and movement. But today, I'm going to be talking
about confidential competing recent past emerging present and long lasting future. I am
Southemic. I am the technical community architect at the confidential computing consortium,
a sub foundation of the Linux Foundation dedicated to this technology.
So I want to start with the past where we're going to talk about kernel to confidential
compute the present, the remote attestation agendas that we're dealing with right now,
confidential containers and CVMs, and then realizing the promise of open security for sensitive
compute, which is really the promise that confidential computing makes. So what is the history behind
confidential computing? And I apologize for these slides being a little bit smaller in text,
but there's an interesting history here. So the concepts behind privacy are very, very old.
They are hundreds or thousands of years old, depending on what culture you are looking at.
But when we look at the intersection of privacy and compute, the first time that we really see this
conceptually realized is in 1978, which was the this right up here, on data banks and privacy
homomorphisms. Now to be clear, this was the same here that BG's fever night was the top
song of the year. So if you remember that song, that might bring you into a place of remembering
that we did not have a lot of compute technology at this time. It's very conceptual. Now in 2009,
we got FHE, and that allowed us to really unlock confidential computing. In 2015, we got our first
TEE's out of Intel. We then got the confidential computing consortium that I'm representing today,
and we have had many players come on board since then in the 2020s and beyond.
But I'd like to step this back to a slightly broader part of history, because I think it's absolutely
essential to understanding confidential computing, especially now I would like to ask this question real
quick. For everyone in the room, can you raise your hand quickly? If this is your first time in this room,
if this is your first time with confidential computing, great. That's why I'm giving the first
talk of the day and making it as like on the floor as possible. So in 1961, we had the first ideas
of a secure kernel, and this came from the Farante Atlas computer. In 1971, in how really
does its first chip? This is also the first time that we see a reference to the kernel generally
and documentation, even though it is not often formally defined before this point. In 1975, and indeed,
we got a bit of a gap in 1985 arm, 1995, in video. I think this is a really, really interesting
to show that no matter at what stage these corporations get involved and invested in the
production of compute, they are all converging on confidentiality and security at this time,
and I believe that's probably why you are in this room. Now confidential computing runs over a
secure kernel. I used to work in a space where we were working on distributed surveillance
algorithms, looking at the way that groups of people behave on the internet, and you can often
use Linux kernels historically to be able to look at these algorithms and see what the value
and the rate of information transfer was in a group of people leading to the successful release of a
kernel. The only kernel where it is not worth doing that analysis for is a secure kernel. Why?
Because it's a credibly boring. Because there are no opinions statements put into the secure
kernel. The secure kernel is based on a predicate calculus, so you're working only on mathematical
proofs. These mathematical proofs observe an object and subject model, and if you're really curious
about understanding the ways that confidential computing gets upstreamed into the secure kernel
over which we operate, then we do have a kernel sig. And I would really recommend maybe not
joining on the live calls, but looking at the recordings and starting to get an idea of how people
communicate in the space. But it gives you an absolute guarantee. It also was the first time
in computational history where we have a uniquely not classified kernel.
And this is the history that we're bringing with us into the future. There is no way,
especially if we get into a post-contemporality. There's no way of doing security by
obscurity. You can only do security by an absolute transparency such that if I leave the instruction
set on the floor and an adversary picks it up, they still are not going to be able to get into
the system. And again, that is the guarantee that we try to make with confidential compute.
So for a long time, I have been trying to figure out how we secure systems with a human
in the loop, either a malicious human in the loop, or a adversarial actor, but increasingly,
and the reason why I brought these three books for you to flip through today is that I am now
almost exclusively interested in understanding how we secure a system to prevent human
machine, but primarily workload identity, because that is the strongest threat vector that we
seem to be seeing. And the three books that I brought that you should flip through today,
because they're going to give you three very different perspectives on the present moment,
and they're going to help you to understand it, compositely. So I would deception this book,
I love this book, teaches you how to do modern honey pots. This is the one from 2013. This one
terrified me, and as the reason why I decided to join the sub-foundation, because in this final chapter,
instead of giving me the best advice that usually gives me, it says, we have observed
that we are seeing so many bot-on-bot adversarials that are traditional techniques
of trying to bait a human being are absolutely irrelevant. We didn't move in to read these two books.
What are our strongest security approaches to this? This is generated AI security. It's a pretty
good book, but the one that you really want to read, if you are just getting started with confidential
computing or with this idea of security trust boundaries and isolation. I'd really recommend
this one, this is from Mike Bursal, the Executive Director of Confidential Computing. So go
talk to them if you want to shortcut on any of your questions for this, but this is a really,
really good book to start with. I wouldn't consider your on-the-floor technical executive book.
That you're going to get from kernel documentation, etc. But this is a very, very, very good,
epistemological deduction, strategy of looking at how to understand systems. This is absolutely
worth your time, especially if you're just getting started in security. I'd really recommend this
as your base. Now, another one of the reasons why I'm really interested in investing this
is because of this paper that came out while I was at National Institutes of Health.
We were unable to release a couple of large data sets in the Washington DC area, which is where
NIH is based, because there had been a breach of Netflix data real raw customer data in a Netflix
data set that was local to the DC area, and it was sufficient to have just that Netflix-breached data
and the data sets that we were trying to produce, which are scrapped to the federal scientific standard
of privacy. But if you in a way, those with another data set, then you can use spark vector,
mathematics, and you can absolutely identify an individual or a group of individuals, and look at
those lower bounds. This is what adversarials do. This is what they calculate before they decide
to try to bake the end of your system, to see if it's worth their time. And what that means to
me is that confidential computing and privacy enhancing technologies are only going to become
more important. They are going to become more important because right now, the legislative and
regulated idea of what is confidential, of what needs to be held private, is absolutely insufficient
if you're looking at the modern landscape of threats. It is true that there are many data sets
sitting out there. Right? You're Netflix watching patterns can make you re-identifiable. So if
those get breached, you could be in a bad situation. So I do think we're going to see a massive
expansion of privacy enhancing technologies, and we're also going to see a bunch of composite threats
come through in the next five years. Hopefully, very, very likely if you're sitting in this room,
you're not going to be dealing with the breach side of it. You're going to be dealing in the
solution space. So in order to understand how we protect data and now that data is so enriched,
there are three states in which data can exist in transit, at rest, and in use, confidential computing
aims to protect the compute, protect during the bitflex. There's three threat vectors that this
strongly protects you against. And I use these because I'm often having to communicate to people
that are just starting to understand confidential computing and whether or not it's worth the money.
Every single one of these is way more expensive if it breached than investing in a year of confidential
compute. So inside of threats, during data analysis, this is really important to understand that
we're isolating all the way down to the workload identity. Such that if I have a power user,
and they have supposedly all access to the data at all times, you have only cleared specific
individuals and specific workloads that can execute into that space. So even if they wake up on
about day, even if someone steals their login information, this can be a setting with a couple of
additional controls where you've got a very, very high bar for security, particularly if you're
dealing in the GPU massive, massive data space where you can have a massive dump. Number two,
compromised applications, send it, handling sensitive data. This is what we typically think about.
This is your financial and health care data sets. It just has to do with the sensitivity of the data
within them. And then number three, what we're saying much more of now, is confidential, multi-party
data collaboration. I'm going to go a little bit more into detail on how and why this is done.
Let me go to our use cases. So the threat model that we are dealing with in confidential compute
is very big. Right now, there's a lot of attention around regulated, but it is for both regulated
and non-regulated industries because they share a growing composite threat. I do want to mention
that there's a really, really interesting, at the edge of understanding privacy and compute,
humanity is going to have a really, really interesting talk later today on how they're trying to
get this done. So for those of us, again, about half of you are new to this dev room,
how does the use of secure primitives enable confidential computing? So there are four
security primitives involved in confidential computing. Confidentiality, I think that's pretty
straightforward, protecting sensitive data from an authorized access, even in especially during
processing, integrity, making sure that nothing has been altered. Attestation, which
verifies the trustworthiness of computing, and we're going to go a little bit into depth on that.
And very importantly, in this case, a hardware route of trust, a foundational,
a mutable hardware component that anchors security operations like encryption, secure
route, and system trust verification. And to really, really make clear how much that is essential
to this before this dev room was called confidential computing, it was called hardware-added
trust execution. That is what we are doing today. So I wanted to add a little bit into
a remote attestation and confidential computing, but I do assume that if you are interested in this,
that you attended or will look at the recordings for the attestation workshop that was yesterday,
or a lot of real and good work was done, and there's going to be a dev room tomorrow,
which you've already seen. You should absolutely attend. It's going to have a lot of the same
faces on this room because they are so intertwined. So remote attestation is a security mechanism
that's used to verify the trustworthy of remote systems runtime state. Our focus here
is one time verification, evidence-based trust, dynamic security, and secure communication.
If this is new to you with the word attestation, in security, we also have supply chain security,
and they will often throw around the word attestation 100% of the time, they mean an S-bomb
attestation. Can I attest to my bill of materials that these are true for a moment in time?
That is not this. This is a very technical definition for remote attestation,
and make sure that if you're talking to someone outside of CC, that you just make sure that you
get the attestation definitions right off the bat, or you may be talking past each other.
Remote attestation, right? So we have an understanding of this, but I just spent an entire year
listening to every single confidential computing consortium discussion on this topic,
and this is my favorite quote. This is from November 4th from an engineer in the attestation
sig. Attestation gives you an organizational endorsement of proper governance by showing measurements
are expected by the infrastructure. This seems to be the language that communicates this very clearly
to non-engineers, and it's the one that I really like for myself. And in this, if you're at the
workshop yesterday, this is something that we really really got into. This is not my area of
extreme expertise. We have those experts in the room, but we have authentication, and we have
attestation. These are both different and combined ideas. You can have the attestation key,
the AK, and we have the TLS identity keys, but I really want to move us on because we need to be
really focusing on a protocol integration that ensures attestation is integrated, but does not
become a replacement for our understanding of authentication. And there are different things.
Authentification confirms who is making the request, and this is at the TLS level.
Attestation confirms where and how the request is made.
A couple of the resources that I find interesting and useful here is the attestation at the
TLS level. There are a couple, I believe, some of the authors of this are in this room right now.
There's the device attestation model for CC from Intel, which is worth reading as an overview.
And the attestation dev room tomorrow, which we have already discussed.
So attestation is one of the most critical primitives in confidential computing because it ensures
that we can run workloads securely. But what about in run environments? That is a really
fun and interesting question that we are going to get answered for ourselves today, and a top
coming up at 1-10. So secure primitives ensure that we have the building blocks,
attestation, encryption, secure storage, and that those are in place to support trusted execution
and secure data management. And another really good resource for this is one of our open
source projects, Keystone, which uses this over-risk file. And I know that we have the definition
for TEE's before, but I'm going to borrow again from Mike Bursel's slides because this is the best
visual that we have for this. There are three types of isolation. One workload from workload isolation.
Number two, host from workload isolation. This is typically what you're going to be seeing if you're
just throwing something up into the cloud. And number three is workload from host isolation.
Now, this is not something that VMs and containers can traditionally do.
That is why within the definition of the CCC's definition for this, we absolutely rely on hardware
attestation because it allows us to handle sensitive data and sensitive applications with the complete
isolation down to Type 3, which implicitly includes Type 1 and 2. It's the highest level
security that we can provide for computer data. And that very fundamentally is what we mean
when you read the words that confidential computing is the protection of data in use by performing
computation in a hardware-based attested execution environment. So we've got confidential computing
and confidential CVMs. So with CVMs, the emphasis is providing a secure and isolated virtual
machine that can run applications. Now, we see the major shift from digital to EEs to full confidential
virtual machines, leveling using AMD and Intel's chip bases. Our key challenges that we're trying
to fix here are measured boot attestation and memory encryption. A really, really good session
right after this is going to demystify that forest. Now, you have to understand confidential containers
as well, which are extending confidential computing into containerized applications. And they secure
containerized workloads to be run in a secure isolated manner while we're doing data and use.
There's going to be so many good talks on this. But if you are really interested in understanding
the build-up to confidential computing beyond today's talks, I absolutely recommend confidential
computing demystified from as well. A big part of confidential adoption, confidential computing adoption,
is to allow for cloud-native workloads. And at 1245, we've got yet another talk on trust no one
secure storage with Coco, very worth your time. One of the most compelling use cases right now,
so when you look at the technology itself when we're looking at the open source projects,
I tend to like to break them down by chip. You're looking at either cloud environments, mobile
IT, or we're looking at the frameworks and structures that allow us to do distributed systems,
like their clues. These are slides from red hats, oxal-sad. These are excellent. So without
giving you a specific use case, you can now understand that it's partner interaction to
protected data sets trying to interact. Secure cloud burst, right? This is particularly
for like medical use cases right now where they need to burst out with the has to stay confidential.
IP protection, edge use cases, total time isolation, when you've got multi-tenants in the
workloads base, and digital sovereignty. This slide I love, though, because this shows you
the likelihood and distribution between bare metal and public cloud, which really does make sense
depending on the use cases. If you have experience in this space, you understand that these also
align to some security standards. To the actual use cases that I find very compelling,
I'll go through these quickly because you can get access to them. I found the use case
of using confidential computing to store and compute or execute over sensitive databases for
human trafficking, very interesting, because it's the first time legally that we have been able
to do so. Confidential computing provides such a high bar of controlling sensitive data,
securing sensitive data that we were able to begin working across different locations on the earth,
not sharing the data, but simply allowing workload execution into the local space without breaking
any of the regulations without reproducing data sets, which would be harmful to reproduce. This
is getting above and beyond typical regulation, meaning we are working in a paradigm shifting space.
Another topic that's absolutely worth your time, you want to look at sort of the biggest scale
and the biggest efficacy of this. It's going to absolutely be sovereign cloud. And a great
example of this is Italy, Switzerland, and France using this to combine their efforts. These are
three countries with very different privacy expectations, so it's very interesting to look at this.
So regulation, we got done is the first example of a clear, written requirement in which confidential
computing fits all of the use cases. So in Article 8 paragraph 2, we want to ensure confidentiality
in use. Those are the two words that we need, confidential computing, secure site in use,
and allows for isolated, productive processing, and it is the unique solution for securities
data mandate in this case. Other things that you must be paying attention to are the CRA,
the IATF draft, which many people in this room have been working towards, and the AI control
matrix, which is coming out in a couple of months, from the cloud security alliance, and many
of the CCC members are actively engaged in making sure that CCC is represented in that. You'll get
the slides. But this is really getting as a composite understanding. You cannot understand regulation
without understanding all of the regulation at once, so make sure to look at these. So CCCs
exploding, regulators are watching, and zero trust is evolving. And for everyone in this room,
whether you've been putting years of work towards this, if you are just considering that this
might be a place where you want to put your engineering time, understand how cool this is.
This is not just about protecting data. This is about building compute, where trust is built in,
and not added on. A couple of the things I think are very cool that are coming into this list. The
future of Austin is here. It's on these sessions. And I think we've covered it all. This has been
a quick intro to the CCC. If you have not joined a Linux Foundation generally, as a
corporate member, or as an individual, anyone interested in the internet, you can join in our
SIGs, our special interest groups. Somebody might find really, really interesting. Our
attestation SIG, or if you are generally more interested in how we're getting this move to
into regulation, join the governance risk and compliance SIG. Again, this is a fully open institution.
You can join any of these calls, and you can always look at the recordings, come talk to me
if you want to learn more. Thank you so much.