Hello everyone, I'm kind of nervous because it's been three years of no conference on
my side, so I'm really happy to be here today because, wow.
Just a quick screencap of what it was like last time, Ed was really presented just for
the project because I did a conference like at the last post that was in person and it
was more of a call for collaboration, I still named collaboration but today's presentation
is more like on what happened since that moment which is 2016, so and this is what it looks
like right now, so for people using it they're aware but this is it.
So this is the plan for the presentation today, who I am, like what is Ed's, why Ed's, what's
new and what's next, I saw that most of the people here already knows what Ed's is so
I will try to go faster there so that we have more time to talk at the end.
Who I am, I'm Cyril Arion, I come from Canada, I started in Sergo Open Technologies in 2017,
this is me, I'm currently in the main Ed's maintainer, I certified the privacy beast and
years are passing so fast, 2019 and since that moment I'm actually trying my best getting
funding and being paid to actually move the things forward in the mission of facilitating
accessibility to security and confidentiality for most people, so this is a challenge because
everybody needs confidentiality and privacy but they're not necessarily tech savvy, so
the goal of Ed's right now is more to bring it accessible to everyone, reducing the friction
and that's it.
What is Ed's?
Ed's can be seen as two different things, it's basically a built system I would say
and the outcome is a runtime environment, so the runtime environment is based on core boot
as of now but it could be like inside of UEFI and the DXE but what I'm testing is more a
core boot payload, so Ed's right now is more a core boot payload and as of now we will
call it a runtime environment and environment, so it's core boot and Linux has a payload,
so when you configure a core boot you can configure it like to have Linux as its payload
and basically like I said before, Ed's is the built system preparing the kernel and
the init.rd, you have all the tools needed and the scripts which are boot policies which
actually creates the user interface and everything that is behind to make it usable.
So core boot here, Ed does an abstraction outside of the core boot configuration, sorry,
and basically, Ed's actually core boot as a configuration that is inside of the GitHub
trees and it defines also the Linux configuration that will be used to define only the needed
kernel modules that will be compiled in and if there is outside modules that are needed
let's say the wired card or anything else, it's loaded on demand.
So the most important part for us right now is to define Ed's, this is the only thing
I want to say about core boot, unfortunately the openness and ownership and the auditability
of the core boot part of the code will depend on how core boot is open.
As we heard in the previous conference that was given by Michael, we have a problem because
less and less platforms are actually completely open source without blobs, so unfortunately
we shift the responsibility to the user to define his own threat model and decide which
platform is going to use to attain the privacy and confidentiality data is there.
The idea here is that if you don't have native initialization of the hardware, if you depend
on FSP and memory initialization blobs, you have to have faith in those blobs to actually
do what is expected and on the models that we have there like ID bridge again, this laptop
the X230, soon there's going to be as well the T1440P will be supported with native RAM
initialization, it's coming.
Other than that, then we have the KGP D16 which Michael again talked about which was
dropped mainstream but dash arrow core boot I think is based on 4.16, I think so.
So a lot of other features that were there until 4.16 are merged in, core boot changed
the release cycle, so now it's like every three months, so release are going faster
but it doesn't mean that so much happened in between release, it's just that the release
are going faster.
Power 9 is now supported by core boot, it's going to be supported inside of ads, I came
and fuzz them, now I will have the TPM modules to be able to test this at home and it will
be, it will land inside of ads later on.
As opposed to an open source firmware, this is what you would have like inside of a closed
source supply chain environment.
So this is complicated, I'm just doing that as a reference.
Normally you have to have the like I said the FSP, the TynoCore like to implement like
the UFI implementation and after that all the companies are doing a little part and
the OEM is actually responsible for 10% of the code that is there.
So this is true for all computers but Apple that is there which is responsible to actually
develop the firmware completely and this gives a good posture because they support
the hardware longer.
For other firmware, for other company vendors the firmware is not that long supported and
we saw it with the X230 which is not maintained anymore, there is no microcode updates, this
kind of stuff is happening for the firmware level.
So on the other side with ads as an open source firmware, we have complete auditability for
the platforms that are completely open source.
So the core boot source code is auditable, the Linux kernel is auditable, you can see
like the source code for that version plus the configuration that is pushed inside of
ads.
We depends on Linux tools only to do the magic of ads, so basically you have module dependencies,
you will see links later on to actually go directly in the source code to see where the
modules are and what they do and this permits us to have really streamlined policy which
is right now GUI init inside of ads and GUI init is responsible to take Linux as init
and then point directly in the policy that you want.
The reason why Trimal did this is because anybody here that would want like the policy
which is basically a bash script to do something else could do it and customize it like super
easily.
Bash is easy to read and understand as opposed to compiling stuff like once the tools are
there basically your policy is just saying like okay I want to show this and when you
click that it does that.
So for developers it's easy to review and see and collaborate as well.
So the small note that I put there is that the reason why Linux is really interesting
inside of firmware is that you can reduce like the size of the kernel to only do what
you want it to do.
So on ads it's a really small kernel like only containing what is needed to initialize
the platform outside of Corboud and since we are able to also build models we can support
for example USB as storage as model and then when we need storage from a USB we call it
on demand.
So we load the modules, we measure the modules and after that we load them.
And the same thing for a USB keyboard, if you don't need a USB keyboard it should not
be there so that's what happens for laptops.
That permits to remove a complete old class of attacks because if you don't have USB keyboard
and you don't have HID as a driver then you cannot have a rubber ducky attack simply because
the kernel drivers are not there so you can reduce the stack, the get-acc surface as needed
as well.
So this is it, so here we are going to talk about Linux as a bootloader.
What is a bootloader real quick?
It's what is between the firmware and the OS to actually parse configuration and boot
inside of it.
Sorry, my mount is dry, I'm not used to two-conference anymore.
So yeah, if you use the kernel as a bootloader then you're able to bypass completely C by
us or grub as we see normally.
So if you have Linux again and you have scripts you're able to parse the grub configuration
and you're able to display it in boot inside of it.
And the Linux tools that are there are actually the basic ones that are needed.
So we have Busybox, we have Cripsetup, LVM, the TTM tool stack and WipTel, NFB WipTel
which permits us to have something like that.
So once you're having an operating system installed and if you don't have an operating
system installed, Edge will detect that nothing is on the hard drive and will propose you
to boot from a USB disk.
And that USB disk could be just plain ISO and the detached signature if the distribution
is providing that.
And you can verify the ISO prior of booting inside of it.
Again it's Crip, we can do whatever we want so that's what we can do.
Here in action is the main policy that is there.
Like I said everything inside of it as right now is based on one policy which is GUI init.
It's not really clear.
So basically up here what you see is that the normal boot policy is GUI init.
Basically we're mounting the slash boot in read only.
We're verifying here because since we have an open source and we have Linux and the tools,
we're based on GPG tool stack to be able to actually first when you own the platform
you inject your public key.
If you don't have a public key and private key you have to have a USB, a USB GPG smart
card and Edge will say okay please inject your public key and if you don't have one
it will help you to own your USB smart card.
Once this is done the public key will be injected inside of the firmware and that permits us
like to actually sign the content of slash boot.
So here what you see is that it was signed with my key.
So all the content of slash boot is verified.
The default boot configuration is also signed so it's verified prior of jumping inside
of it.
So all you see there is the verification of the content prior of trusting it and once
this is done it asks us like for the TPM disk unlock key.
I think I will cover that later but this is an example of what can happen.
Our recent change inside of Edge is that instead of trying to craft a crypt ad entry we extract
the NETRD to see what the operating system is trying to do.
There's some operating system that we're implementing for some reason two crypt tabs.
So instead of trying to craft one we copy like the form of what is expected by the operating
system and we just inject inside of it the place where the secret is supposed to be.
The TPM will unseal the secret if all the measurements are good so the firmware is good.
After that like if the drivers loaded are the same as when we seal the secret inside
of it it verifies also that the looks header is exactly the same and if all of those things
are as expected.
An additional NETRD is created including the crypt padding question and the secret and
this is passed to the NETRD of the operating system so we're able to actually boot inside
of an operating system without typing your passphrase from a boot prompt that you don't
know if you should trust or not.
So as it's trustable because everything is measured it has tested to you and then you
can type your passphrase there because you're trusting it.
So that's basically what we can see.
I have laptops here if you want to talk later on.
The demo that is there real quick is something that I can launch on my laptop.
I acted last week to be able to present it right now but you can have like a flat partition
with ESO inside of it.
Now you can just say okay media scan you point it like to the partition containing your ESO
in question.
It will ask you like what ESO you want to boot.
It provides like detach signature so basically at that point what you see is again as verifying
the ESO with the detach signature that guarantees like the authenticity of the ISO and the integrity.
Once that is done it provides you a list of the grub entries that are there.
You select it and at that moment like you see the boot options that were passed inside
of the grub configuration and at that point a minute later you're inside of tells.
So it permits you to actually sign ESO that you did yourself you created yourself any
live ESO that you have once you verify it like the integrity of it.
You sign it with your key because you already have it and at that point you can guarantee
that like a USB drive that you have with multiple ESO will be bootable whenever you want.
And in that case it permits you to boot inside of tells and tells guarantees you that micro
indemnization will be done.
It's in the memory so if you're in an emergency situation or you're in a coffee that you
don't trust you remove your battery you work as you want to and at last minute you just
unplug your power cable and there's nothing in memory anymore you left no trace you did
what you had to do and that's it.
That's really important for a lot of customers and this is one of the most important features
of ESO.
It permits you to guarantee that what you're going to boot inside is going to be as expected.
So I covered that already Linux kernel and it contains the standard Linux tools that
we need and the policy as well is responsible to fixate the user experience.
As a system most of your people are developers.
This is a slide pointing exactly in what you should be looking at if you're interested
into contributing or customizing it for yourself.
One of the good thing that we have right now is that we produce ROMs for the platforms
that we support so every time that there's a commit made inside of it Circle CI is actually
watching the repository and it builds all the ROMs for all the platform with different
cache system and everything.
I won't cover that today but this is what is cool like if there is just a change in
the policies the ROMs will be created inside of like five minutes if we have cache of what
was built before and that's it.
It contains the hash as well sorry it's cut at the bottom but each ROM that is produced
contains hash of everything that was built and it's supposed to be reproducible.
There's funding to make sure that Ed's is backed as being reproducible.
Tramil Hudson is helping me on that.
It will come in the next year as well.
Why Ed's?
I think I covered it like already.
The main problem that we have like with a proprietary firmware is that there is duplication
of code in multiple parts.
So we're trying to recreate the wheel and the idea behind Ed's is that we should not
do that if we have already a kernel that permits us to drive the hardware that we want.
So instead of duplicating at that part here like the drivers to be able to drive the graphics
to be able to control your keyboard, the bus and everything the kernel is able to do it
and does it like really efficiently.
Another reason why we love dealing with the kernel instead is that we can control the
IOMMU directly at the moment that the kernel is launched from Coreboot.
So at that moment if we specify that we want like to have like the graphic card not having
the IOMMU because we're going like to boot inside of Cubes OS for example it can be
defined there and it's going to be properly set up for us.
Okay, 10 minutes.
So again links here if you want to click.
The policy that we use as I said is you're in it right now.
I will cover that like more in details later on and one of the important change I will
cover it like in what is new in the next slide is that we have maximized ROM.
Maximized ROM are actually complete, it's a valid complete ROM.
It includes Intel ME, it includes an unlike IFD, it includes Coreboot and the packed kernel.
So the image that are there inside of CircleCI as artifacts are actually externally flashable.
We create like top and bottom image.
So if for example the X230 when you open it up there's two SPI chips that you need to
reprogram externally.
Once that is done you can update internally flash ROM is inside of ads as well so you
have control and you're able to like to upgrade as you want.
Why ads?
There is extensive TPM usage.
The reason why we like ads is that there is two sealed secrets inside of the TPM.
The first one is happening the first time that you flash your firmware and it's sealing
like all the measurements that are created from Coreboot.
Coreboot is configured to be in measured boot mode and it extends the TPM PCR to a PCR.
Everybody knows what PCRs are in TPM basically.
So all the measurements are being done in the PCR2 from the coreboot part.
After that when ads start, when the payload is actually loaded which was measured inside
of the PCR2, ads extends a couple of other PCRs which are then used to make sure that
the integrity of the runtime environment is actually the same as expected.
So the first seal secret when you flash your firmware, the next time you're going to reboot
it, ads will say okay you either don't own the TPM so you have to own it or otherwise
it will say okay we have a couple of measurements that were provided by Coreboot in measured
boot mode so we have to seal them.
When you seal them, it will create a QR code which you can scan on your phone or if you
have like a NitroKey Pro or a LibreM key and you use like the HTTP version of the firmware,
it will ask you to seal that secret as well inside of your USB security download.
So at that point you have the measurements of the PCR4, 5, no it's another slide, sorry,
no it's not another slide.
So basically you have like the measurements of PCR0, 1, 2, 3 and 4 that will be like inside
of the first sealed secret which guarantees like the attestation of the firmware.
So you boot your machine, you plug your USB key, it will flash green if the measurements
are good from the firmware alone and after that if you set a default boot configuration
you're actually using all the other PCR measurements to seal the secret plus the lux header that
is extracted because we have Crip setup and you're going to seal it with a passphrase
that you define at that moment, at the moment of sealing the secret.
So when you're booting, it's what I showed you before like in the other screen that was
here, when it's asking you to type your passphrase it's making sure that all the measurements
of the PCRs are exactly the same in an attempt of unsealing the secret inside of the TPM.
So at that point either if your password is bad or the measurements are bad as we'll
just refuse to boot your system and it will say to you PCR mismatch and at that point
you should be worried and investigate.
So that's it for that.
Why is it important?
Because yeah, the secrets that are sealed inside of the TPM memory are actually making
you sure that you're in the state that you expect prior of typing a passphrase.
For use of typing passphrase in weird environment, this is an environment that is trusted.
So at that point like anything that you do inside of eds and that opens the door like
to add more feature will work as defined.
I will go faster because I have only five minutes.
The reason why maximize boards are important is actually that on an OEM version of the
firmware this is what we have.
The Intel IFD is locked, the IFD is basically the description of the region inside of the
firmware as defined there and ME is also locked.
So if you want to take advantage of all the firmware space that is there to add tools
you have to unlock the IFD and you have to unlock ME.
So the reason why the maximized, this is a configuration of the maximized board.
This is the extraction that we have here of the important part.
So flash run here like on the legacy board or if you're coming from Ivy Rain for those
who are interested in that project is that you can only flash the bias region.
And the bias region is only having eight megabytes by default on the legacy or the OEM version.
So if we externally flash and we nerter ME we're getting more than four megabytes additional.
So if we add that inside of the bias region we're having like 11.5 or nearly 12 megabytes
of usable space where we can add more features, we could even add Python there if we wanted
which is something that I want for a really long time.
So this is what it looks when it's modified.
Actually you see that the bias region is equivalent like of XBE for FFF so basically
it's near of 12 megabytes.
Yeah, I covered that.
Actually the reason why we love it for the redistribution, the issue that we have on
blood redistribution is that inside of the edge repo we owe the scripts.
The scripts are being called by circle CEI to actually download the images from Lenovo.
We extract them directly on the CEI.
We're able to extract ME from there.
We're able to nerter ME from there.
Then circle CEI is responsible to build Corgut, use the module that we're extracted, validated
and everything and from that moment we're able like from a simple script like that
to build a complete run image and we just dodge the legal issues.
So whatever circle CEI is building like that, I gave it as an example here, provides like
artifacts.
This is a build from circle CEI.
This is like the output of Corgut which was able to stitch everything together and at
the end of the build and you have the image I was talking about.
So you have the 12 megabyte full image that is internally flashable and you have two image
for each commit which are there provided by the circle CEI for 30 days after the moment
of the build.
That permits you to externally flash and then it permits you to internally flash forever
after.
The OEM way is like that, yeah sorry.
The WipTel support is for either servers and BMC.
So it would be usable on the KGP D16.
This is what it would look like from a remote serial connection.
So if you're connected on the BMC remotely, this is exactly what you would see.
The HOTP card dongle could be in your server and the TOTP is what you could check remotely
if the time is good and then you have the same option but console based.
This is what we see if we're having graphical frame buffer on laptops and desktop.
The OEM factory reset, OEM factory reset with ownership wizard was upstream.
So it looks like that asking you like to what you want to do, giving you options that are
really important if it's not you who have installed your operating system.
This is what I pushed forward because if you don't install your operating system yourself
then the LUX encryption key could be intercepted.
So you want to re-include the content of your drive and once again, since we have Linux,
we can do that directly inside of it.
You will have like to look at that for yourself.
I won't have time to cover that but this is what it is and the main thing that is really
nice for developers is that we now have QMU and QVM boards with software TPM support.
So all the images, mostly all of the images that I provided were taken from the QMU version.
This is what it looks like when you build it.
So you can inject your key and then after that you can run it.
That's how it looks and then you can add your recovery shell directly from the terminal
and you will see the output of WipTel and you can develop and test as you go.
And this is what's next.
I'm sorry I won't be able to cover it directly but I gave link on everything that the work
is happening right now.
TPM 2 support is coming so new boards will be able to have it.
Cleanroom GPT key generation is the next thing I'm working on to be able to remove the need
of having your USB security dongle because people want to test it but don't necessarily
want to buy any Trukey which was a problem before.
Write protection is coming so if you want to look at this and poke me there or any question,
SPI write protection was developed by 3MDeb.
It is now in the PR that is supposed to be merged in the next couple of days when I will
have a time.
International keyboard support will come because right now it's just US keyboard which is a
problem for a lot of people and randomization of the mic address will be possible directly
in the GBE partition inside of ELS and being reflashed.
And this is it folks, reference.
I really recommend to watch the original talk on ELS if you have like more in-depth questions
because the background didn't change and that's it, thank you.
Do we have time for questions?
Okay.
Yes.
You mentioned support for TALUS board PC systems, how do you support them since they
don't have TKM?
You said the TALUS 2 platform supported?
The Raptor, yeah.
The question is does the TALUS 2 have a TPM chip?
There was a connector that was a really big adventure, I will try to make it really short.
The port was done like with 3MDeb here and actually there is a TPM connector but it was
not working properly.
So we had like to do research to be able to actually make it work on the panel but yes,
there's no TPM inside because it's against their mentality but you can connect one but
it will be the one that you buy from 3MDeb because you have to add a TPM chip.
You have to add a TPM chip but it's available from their shop, so yeah.
Another question, yeah.
Do you do remote attestation if you don't or are you interested in it?
It's something that I don't have, oh yeah, do you do remote attestation?
Actually VaultBoot did it, VaultBoot is actually a fork of ads.
I'm looking into upstreaming the code but I would say that any person that is interested
into that kind of feature, I would guide you to see what they did because they have a proof
of concept that is really interesting on the Raspberry Pi for remote attestation and there
was a board config for Coreboot there as well and everything is there.
It's just a trying to upstream but I'm not against it but ads as of right now is more
targeting users to actually own and being able to verify for themself but remote attestation.
So the question here would be like is remote attestation possible, yes, someone is suggesting
to do it like remotely on the phone, it would be totally possible, there's no, please contact
me, okay, cool.
Another question maybe, no?
Sorry for this dense presentation, next presentation I will be better.
Thank you everybody.
Thank you very much.