Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1390 Thanks!
So for the next talk on
Cars West Stage, we go
into the fast track, into the
shorter talks, and nevertheless,
this will be an interesting
insight into something that
has a lot of implications
for transparency and systems.
And that's why the talk is called
system transparency, and it
will be held by Kai and
Kai as I got for both of them.
And I give you the stage.
All right.
So the
2020 is only a few days away,
and while we do not have flight costs or
sex robots, we do live in a dystopian
nightmare, a dystopian
nightmare that our computing is
more and more controlled by unaccountable
Silicon Valley companies.
This way, there's no turning back.
The centralization of computing and data
will only continue into the cloud
because this makes things cheaper and
also allows us to do things we couldn't
do before
30 years ago.
We were faced with a similar threat.
Proprietary software stuff a competition
prevents the extension of software.
The result was the free software movement
that freed openness
and freedom as its core tenets.
Today, we recognize that open and free
software is a superior software
development model.
Ironically, free software won't help us
this time, because free software is one
of the reasons why these cloud companies,
as a business model, works so well.
What we need to do instead is to take one
of the core ideas of free software
transparency for the user and reimagine
that for the worlds of power
and SaaS.
So, OK, and I'm
from Belgium, and today I want to tell
you about the system transparency project
here. And of course, nothing
I will tell you here is just my idea.
I'm merely here to tell you about it.
And this this transparency project mostly
grew out of the Open-Source firmware
community.
You could fight here right behind the
stage.
So this transparency
has the goal of making the software
running on a remote server
that processes third party data
expectable. But that particular third
party to do that,
we proposed seven concepts.
The first one being that we need some
kind of provisioning ritual because
these servers are
hard to get get to handle by,
right. So we have to do this in
transparent clouds.
And what we need to do is give every one
of these servers and unique
platform identity so we can
decompose this cloud individual
service, which allows us then
to make specific statements about a
specific service.
Second, we need to make sure that the
firmware the first and most previous
courts that executed on the machine
is known to us and can
be changed by an attacker.
To do that, we need to have some kind of
integrity protection for the firmware
running on the machine.
Oh, sorry, I thought.
Because we still have physical attackers,
we need to make sure that the machine is
somehow temple resistant or at least
evidence so we can see when
at least attackers try to change the
former and thus
try to protect the system,
then we need some kind of platform
attestation, meaning that when before
I connect to a machine, I want to make
sure that the software runs and the
identity test is not to me before
I send my data right.
Otherwise, I have to problem that my
data may be handled by a software I have
no idea about.
And maybe it's abused.
And because all of this
detection and also the protection
I take, the protection of the former is
done on the binaries.
We can only, but we can only expect the
source code. We just establish some
strong link between the source code we
were able to inspect.
And the binary that actually handled
by the special attestation mechanisms
reproducible builds does exactly that
right? Because I can recall Polish
source code, I have inspectors and I will
get the same binary that's running on the
machine.
Then we need to limit the system access
because even if you have integrity
protection from there and we know
everything that has been executed as
party boot, we can still
have a malicious administrator
locking into the system and changing
things in ways we can't control.
So we need to limit the system access.
We need to have some kind of immutable
infrastructure.
And lastly, we need an transparency
lock for all the software running on a
particular server so we can
monitor not only the current, but
as the past actions of platform
owners. So we can all of them
somehow like the certificate transparency
mechanisms we have if Pichai.
So this intersperse is not just
a bunch of concepts.
It's an actually work implementation
for that to use the Super 11
as ETF, which is the midrange
server bought from Super Micro,
it has up to four cores, 64
gigabytes of RAM to
take you a bit Nicks and PCI Express.
You can get these boards for less than a
thousand euros on the market, and
these can be used to use to do
everything. I will tell you now.
So in order to have some kind of
unique platform identity we use and
chip, that's already sold it onto this
man, what's called a TPM
that TPM contains and unique certificate
and a private key for that certificate
that's inside this ship that can
never leave it.
We can use that to use our unique
platform identity.
And also it allows us to record
what's puttered, what's executes
this policy, but say sorry, TPM
has a special feature where it's
because the cryptographic checksum of all
the code was executed as part of the boot
process. We can then later write that
out and verify that, OK, it
booted exactly what we expected,
including the operating system.
Our X11 runs open source firmware,
so we have a stack of codes and
Linux boots covered in the early
initialization of the hardware and then
later execute Linux boot,
which puts into the operating system.
We use our own bootloader
Basilisk boot caught as tribute
to all of the boot process,
especially fetching a new operating
system from the network, verifying it and
then booting into it.
And because we use cobalt
and cobalt can be built reproducibly, we
can use that as our secure initial
states reboot from
We Can Everybody, not only the platform
owner captured the source codes they
call the source code. We run on the
machine, compile it and verify
that this is the exact exact copy
of that which has been recalled by
the TPM as part of the process.
So we can make sure that this is exactly
what platform owner supposed
to run on a machine.
Yeah, as I said, we have a special
bootloader called Sibert that
does all the booting after the initial
hardware set up
be doing, but of course
we don't do a signature verification
and some other stuff and then boot into
the operating system.
We can pretty much any open source
operating system.
So not only our
firmware, but also our operating system
can be built reproducibly.
In this case, we built teakettle,
the initial ramdisk and the complete
operating system to Waldrop.
That is almost the exact copy
of what everybody else has compiled.
We then signed that and deployed for
all signed this hash.
It's like the hash of this, of this
block.
We can also configure as tybalt in a way
that we require more than one
signature. So, for example, if the
platform owner has five administrator,
researchers estimate it can be configured
in a way that at least three of them have
has to sign the image before it's
then booted.
Well, that's all nice.
The core idea of system transparency
is that everybody else writes.
Users can verify what's running on the
system and to do
that. We also
require the platform owner to request
a new X five four nine certificate for
every operating system in which he wants
to deploy on a set of his.
This certificates that contain
the hash of the operating system image as
part of the common name.
And because DCA that issues
the certificate is
working with the certificate transparency
lock.
We have then the hash of the operating
system inside the Appends Only Cert
response lock that's run
by culturelle.
And now we have an open append only
and public sort of
transparency log of all the current
and past operating system images that
have been deployed on a particular
system.
And because as he put before, it puts
checks, that's the certificate
recipients locker contains such a
certificate.
You can make sure that everything that
boots on a particular server has been
verified by us.
So in a nutshell, since the transparency
partitions the entrance point cloud
of servers into a set of individual
servers, the unique
and
so as unique platform
identities, which allows us to do
a specific statements about specific
servers, right? Because we are still
connecting to specific servers.
System transparency also makes
all the code running on a particular
staff visible to the users,
which means that we force
bad actors to lie about very specific
things. So for example, if a
VPN provider and they tell you, well, we
don't keep any logs in order to
verify that you have to ask for us to
figure out, OK, what does keeping logs
means?
We'll resist the transparency.
You can just get their operating system
image, get this off court
and inspect the source code and decide
whether you consider the
implementation of a VPN privacy
respecting you and then compile
that and verify that you get the
exact exact copy of
that. What has been inserted into Cert
transparency lock and then can verify
that OK. The thing of connecting to now
hasn't had that doesn't have any kind of
backdoors.
Now, a malicious VPN provider has to
lie about a very specific thing,
which is this particular server with
this particular unique idea runs this
particular operating system image with
this particular hash, right?
And the more concrete these lies have to
become that easier is to capture them.
Not sorry as
well, since the transparency provides a
public log of everything that has
been done as well in the past by the
operating system provider.
This means that we can
audit and provide more thoroughly
than what we can do before, right,
because we can say, OK, what happens
before we had that?
We have used this machine.
This also means that every platform
owner, every provider has to commit
publicly and irrevocably to every
operations the image before it is
deployed on a machine, which means
we, as a concerned user, can monitor
the certificate transparency log, see for
new operating system images and then
verify them.
And when we decide, OK, there are some
changes that we don't like, we can
either stop using them the service
or a lot of public.
And lastly, system transparency
works with open source firmware,
bootloaders and operating systems.
And this is important because this is the
mechanism that actually allows us to
inspect the source code and somehow close
the gap between platform providers
and platform users.
So what's the future
dystopian nightmare of 2020?
We will hope to grow this as
keyboard and transparency project
into more major operators
absolves project, which means
hopefully that the
as Typekit bootloader is maintained.
We have better documentation, we have
more features as also
we want to support more hardware.
So currently, we only support everything
that cobalt and attribute supports,
which isn't that much.
So we want to grow, especially in the
x86 market, to support
most of us that actually used in
practice.
Speaking of practice, we actually want
to have a first transparent server
running a production by the end of next
year to provide to the public that
this idea can actually work with real
VPN providers. For example,
we are currently piggybacking on the
certificate was part of the effort.
We want to change that and develop our
own certificate transparency lock.
For example, this certificate is
sorry. Suffer transparency can include
then, for example, to source code off
of the things we want to verify instead
of just the pointer.
And lastly, currently leave depending
on the TPM, which runs most of the time
proprietary software.
We want to change that and figure out,
OK, how we can use open trust echoes.
For example, the open titled Project or
something based on this five or something
else.
And lastly, we of course, want to invite
you to join our effort.
So in case you are interested in open
source from the industry and
transparency project, they may want to
check us out. We are just right beyond
the corner. The open source from somebody
is always happy to help you.
And I'm happy to help you
with any hardware you have to, especially
if it's about transparency.
And so if you have a question
now, you can either ask me
or go to our website where you have all
the documentation ready.
And if if you want, just
talk to us in person, you can go to the
open source firmware somebody and catch
up there.
Thank you.
Thank you, Kyra, for a very concise
talk. So we have a bit of time for
questions, you can queue up
at the microphones.
All we can see if there
are internet questions.
No internet questions.
Are there onsite questions?
Come on.
Anyway, if you
feel like, oh, we have questions from
the internet,
oh yeah, the internet, thanks you for the
talk and wants to know.
What about mobile phones?
Now we can unlock bootloader, but no,
I thought it was sorry. I don't trust
that you can repeat it now.
We can unlock bootloader,
but not to lock again.
Sorry.
Yeah.
Oh yeah.
Sorry, give me a second.
OK.
Maybe in the meantime, you
are queuing up. OK?
Yes.
Thank you for the great talk.
A very interesting project.
I've got one question.
One is, can you make
sure you learn about any admin
interaction with the cloud server
in the end?
Because that's one major concern I would
have if I run it on a truck and a
provider of hardware.
Right?
So first, you can expect your practice
Democrats, and you can when you see, OK,
there's an openness h
server running, you know that the system
isn't secure, strictly secure, right?
Because everybody can log in and change
everything.
What we imagine is that either you
forbid any access whatsoever,
which makes debugging a bit complicated,
then you would have to try to change.
You want to do in the server you have to
deploy in your practice system in
Detroit. This makes things very
transparent, but also very annoying.
What we can imagine is that instead of
dropping into bash, for example,
you could have and restricted travel that
drops if it's on some script that
it does allow you some things like
restart server, get some lock output
or whatever.
This, of course, only includes what the
machine itself can do, right?
If you are running in an in the
hypervisor, you have maybe other ways
to look into the system.
This is the classic problem you have with
trusted computing is you need to control
everything or you need to say, OK, my
hypervisor or my hardware running on
it is secure, right?
This is this learning and probably we
can't really solve.
Can I have a follow up question?
Yes, concise question.
Yes, sort.
From what you said, I could imagine that
is a big company side interests
specifically like from large
infrastructure companies from Europe.
Is that the case or
we try to convince some of them.
But I mean, if you go to Google or
Amazon and tell them, Hey, after this
great idea about this transparency,
it's hard to get it right.
But yes, we know
of some companies that do something
similar. Right? So the ideas we have
here, these seven concepts, they existed
somewhere else to right.
And this specific concepts were
introduced to us by the more VODs
VPN provider that
they had this idea initially
to somehow differentiate, differentiate
themselves from the other VPN providers.
OK.
Segment, Andrew,
could you repeat your internet question?
OK. Question is gone.
Is there another question from the
microphone or
no?
OK. I think that's Lance
as perfectly at the end of
the talk. And as
I said, you can visit them at their
assembly and you can connect with them
in any way.
And yeah, I'm looking forward
to next year.
And yeah, round of applause for him.
It's like a.