[00:00.000 --> 00:11.440]  Hello everyone, I'm kind of nervous because it's been three years of no conference on
[00:11.440 --> 00:18.000]  my side, so I'm really happy to be here today because, wow.
[00:18.000 --> 00:23.720]  Just a quick screencap of what it was like last time, Ed was really presented just for
[00:23.720 --> 00:29.560]  the project because I did a conference like at the last post that was in person and it
[00:29.560 --> 00:33.440]  was more of a call for collaboration, I still named collaboration but today's presentation
[00:33.440 --> 00:40.840]  is more like on what happened since that moment which is 2016, so and this is what it looks
[00:40.840 --> 00:45.960]  like right now, so for people using it they're aware but this is it.
[00:45.960 --> 00:51.680]  So this is the plan for the presentation today, who I am, like what is Ed's, why Ed's, what's
[00:51.680 --> 00:56.680]  new and what's next, I saw that most of the people here already knows what Ed's is so
[00:56.680 --> 01:02.400]  I will try to go faster there so that we have more time to talk at the end.
[01:02.400 --> 01:15.640]  Who I am, I'm Cyril Arion, I come from Canada, I started in Sergo Open Technologies in 2017,
[01:15.640 --> 01:24.160]  this is me, I'm currently in the main Ed's maintainer, I certified the privacy beast and
[01:24.160 --> 01:31.040]  years are passing so fast, 2019 and since that moment I'm actually trying my best getting
[01:31.040 --> 01:37.440]  funding and being paid to actually move the things forward in the mission of facilitating
[01:37.440 --> 01:44.000]  accessibility to security and confidentiality for most people, so this is a challenge because
[01:44.000 --> 01:49.280]  everybody needs confidentiality and privacy but they're not necessarily tech savvy, so
[01:49.280 --> 01:54.920]  the goal of Ed's right now is more to bring it accessible to everyone, reducing the friction
[01:54.920 --> 01:57.760]  and that's it.
[01:57.760 --> 01:58.760]  What is Ed's?
[01:58.760 --> 02:04.160]  Ed's can be seen as two different things, it's basically a built system I would say
[02:04.160 --> 02:09.440]  and the outcome is a runtime environment, so the runtime environment is based on core boot
[02:09.440 --> 02:18.080]  as of now but it could be like inside of UEFI and the DXE but what I'm testing is more a
[02:18.080 --> 02:22.560]  core boot payload, so Ed's right now is more a core boot payload and as of now we will
[02:22.560 --> 02:30.240]  call it a runtime environment and environment, so it's core boot and Linux has a payload,
[02:30.240 --> 02:36.320]  so when you configure a core boot you can configure it like to have Linux as its payload
[02:36.320 --> 02:41.600]  and basically like I said before, Ed's is the built system preparing the kernel and
[02:41.600 --> 02:48.520]  the init.rd, you have all the tools needed and the scripts which are boot policies which
[02:48.520 --> 02:54.880]  actually creates the user interface and everything that is behind to make it usable.
[02:54.880 --> 03:04.120]  So core boot here, Ed does an abstraction outside of the core boot configuration, sorry,
[03:04.120 --> 03:13.120]  and basically, Ed's actually core boot as a configuration that is inside of the GitHub
[03:13.120 --> 03:21.640]  trees and it defines also the Linux configuration that will be used to define only the needed
[03:21.640 --> 03:27.120]  kernel modules that will be compiled in and if there is outside modules that are needed
[03:27.120 --> 03:34.320]  let's say the wired card or anything else, it's loaded on demand.
[03:34.320 --> 03:41.720]  So the most important part for us right now is to define Ed's, this is the only thing
[03:41.720 --> 03:48.040]  I want to say about core boot, unfortunately the openness and ownership and the auditability
[03:48.040 --> 03:52.720]  of the core boot part of the code will depend on how core boot is open.
[03:52.720 --> 04:00.120]  As we heard in the previous conference that was given by Michael, we have a problem because
[04:00.120 --> 04:06.320]  less and less platforms are actually completely open source without blobs, so unfortunately
[04:06.320 --> 04:10.720]  we shift the responsibility to the user to define his own threat model and decide which
[04:10.720 --> 04:17.840]  platform is going to use to attain the privacy and confidentiality data is there.
[04:17.840 --> 04:22.880]  The idea here is that if you don't have native initialization of the hardware, if you depend
[04:22.880 --> 04:30.280]  on FSP and memory initialization blobs, you have to have faith in those blobs to actually
[04:30.280 --> 04:37.520]  do what is expected and on the models that we have there like ID bridge again, this laptop
[04:37.520 --> 04:48.160]  the X230, soon there's going to be as well the T1440P will be supported with native RAM
[04:48.160 --> 04:49.160]  initialization, it's coming.
[04:49.160 --> 04:54.480]  Other than that, then we have the KGP D16 which Michael again talked about which was
[04:54.480 --> 05:02.560]  dropped mainstream but dash arrow core boot I think is based on 4.16, I think so.
[05:02.560 --> 05:08.760]  So a lot of other features that were there until 4.16 are merged in, core boot changed
[05:08.760 --> 05:13.160]  the release cycle, so now it's like every three months, so release are going faster
[05:13.160 --> 05:17.720]  but it doesn't mean that so much happened in between release, it's just that the release
[05:17.720 --> 05:19.680]  are going faster.
[05:19.680 --> 05:25.680]  Power 9 is now supported by core boot, it's going to be supported inside of ads, I came
[05:25.680 --> 05:32.240]  and fuzz them, now I will have the TPM modules to be able to test this at home and it will
[05:32.240 --> 05:36.160]  be, it will land inside of ads later on.
[05:36.160 --> 05:42.840]  As opposed to an open source firmware, this is what you would have like inside of a closed
[05:42.840 --> 05:47.200]  source supply chain environment.
[05:47.200 --> 05:50.840]  So this is complicated, I'm just doing that as a reference.
[05:50.840 --> 05:56.520]  Normally you have to have the like I said the FSP, the TynoCore like to implement like
[05:56.520 --> 06:03.360]  the UFI implementation and after that all the companies are doing a little part and
[06:03.360 --> 06:08.160]  the OEM is actually responsible for 10% of the code that is there.
[06:08.160 --> 06:14.680]  So this is true for all computers but Apple that is there which is responsible to actually
[06:14.680 --> 06:20.200]  develop the firmware completely and this gives a good posture because they support
[06:20.200 --> 06:22.480]  the hardware longer.
[06:22.480 --> 06:27.760]  For other firmware, for other company vendors the firmware is not that long supported and
[06:27.760 --> 06:32.760]  we saw it with the X230 which is not maintained anymore, there is no microcode updates, this
[06:32.760 --> 06:37.520]  kind of stuff is happening for the firmware level.
[06:37.520 --> 06:43.400]  So on the other side with ads as an open source firmware, we have complete auditability for
[06:43.400 --> 06:46.040]  the platforms that are completely open source.
[06:46.040 --> 06:52.360]  So the core boot source code is auditable, the Linux kernel is auditable, you can see
[06:52.360 --> 06:56.640]  like the source code for that version plus the configuration that is pushed inside of
[06:56.640 --> 06:58.360]  ads.
[06:58.360 --> 07:07.760]  We depends on Linux tools only to do the magic of ads, so basically you have module dependencies,
[07:07.760 --> 07:11.800]  you will see links later on to actually go directly in the source code to see where the
[07:11.800 --> 07:19.840]  modules are and what they do and this permits us to have really streamlined policy which
[07:19.840 --> 07:29.800]  is right now GUI init inside of ads and GUI init is responsible to take Linux as init
[07:29.800 --> 07:32.600]  and then point directly in the policy that you want.
[07:32.600 --> 07:37.080]  The reason why Trimal did this is because anybody here that would want like the policy
[07:37.080 --> 07:42.040]  which is basically a bash script to do something else could do it and customize it like super
[07:42.040 --> 07:43.040]  easily.
[07:43.040 --> 07:49.480]  Bash is easy to read and understand as opposed to compiling stuff like once the tools are
[07:49.480 --> 07:53.160]  there basically your policy is just saying like okay I want to show this and when you
[07:53.160 --> 07:54.560]  click that it does that.
[07:54.560 --> 08:00.800]  So for developers it's easy to review and see and collaborate as well.
[08:00.800 --> 08:05.320]  So the small note that I put there is that the reason why Linux is really interesting
[08:05.320 --> 08:11.960]  inside of firmware is that you can reduce like the size of the kernel to only do what
[08:11.960 --> 08:13.400]  you want it to do.
[08:13.400 --> 08:22.680]  So on ads it's a really small kernel like only containing what is needed to initialize
[08:22.680 --> 08:29.720]  the platform outside of Corboud and since we are able to also build models we can support
[08:29.720 --> 08:37.000]  for example USB as storage as model and then when we need storage from a USB we call it
[08:37.000 --> 08:38.000]  on demand.
[08:38.000 --> 08:41.280]  So we load the modules, we measure the modules and after that we load them.
[08:41.280 --> 08:45.160]  And the same thing for a USB keyboard, if you don't need a USB keyboard it should not
[08:45.160 --> 08:48.200]  be there so that's what happens for laptops.
[08:48.200 --> 08:54.960]  That permits to remove a complete old class of attacks because if you don't have USB keyboard
[08:54.960 --> 09:00.360]  and you don't have HID as a driver then you cannot have a rubber ducky attack simply because
[09:00.360 --> 09:08.040]  the kernel drivers are not there so you can reduce the stack, the get-acc surface as needed
[09:08.040 --> 09:10.360]  as well.
[09:10.360 --> 09:16.320]  So this is it, so here we are going to talk about Linux as a bootloader.
[09:16.320 --> 09:18.080]  What is a bootloader real quick?
[09:18.080 --> 09:22.840]  It's what is between the firmware and the OS to actually parse configuration and boot
[09:22.840 --> 09:25.200]  inside of it.
[09:25.200 --> 09:30.720]  Sorry, my mount is dry, I'm not used to two-conference anymore.
[09:30.720 --> 09:38.040]  So yeah, if you use the kernel as a bootloader then you're able to bypass completely C by
[09:38.040 --> 09:42.000]  us or grub as we see normally.
[09:42.000 --> 09:46.480]  So if you have Linux again and you have scripts you're able to parse the grub configuration
[09:46.480 --> 09:50.400]  and you're able to display it in boot inside of it.
[09:50.400 --> 09:53.920]  And the Linux tools that are there are actually the basic ones that are needed.
[09:53.920 --> 10:00.960]  So we have Busybox, we have Cripsetup, LVM, the TTM tool stack and WipTel, NFB WipTel
[10:00.960 --> 10:03.320]  which permits us to have something like that.
[10:03.320 --> 10:07.880]  So once you're having an operating system installed and if you don't have an operating
[10:07.880 --> 10:11.640]  system installed, Edge will detect that nothing is on the hard drive and will propose you
[10:11.640 --> 10:15.040]  to boot from a USB disk.
[10:15.040 --> 10:20.920]  And that USB disk could be just plain ISO and the detached signature if the distribution
[10:20.920 --> 10:22.360]  is providing that.
[10:22.360 --> 10:25.280]  And you can verify the ISO prior of booting inside of it.
[10:25.280 --> 10:30.840]  Again it's Crip, we can do whatever we want so that's what we can do.
[10:30.840 --> 10:33.600]  Here in action is the main policy that is there.
[10:33.600 --> 10:39.200]  Like I said everything inside of it as right now is based on one policy which is GUI init.
[10:39.200 --> 10:40.800]  It's not really clear.
[10:40.800 --> 10:46.200]  So basically up here what you see is that the normal boot policy is GUI init.
[10:46.200 --> 10:50.680]  Basically we're mounting the slash boot in read only.
[10:50.680 --> 10:57.720]  We're verifying here because since we have an open source and we have Linux and the tools,
[10:57.720 --> 11:03.840]  we're based on GPG tool stack to be able to actually first when you own the platform
[11:03.840 --> 11:05.520]  you inject your public key.
[11:05.520 --> 11:12.600]  If you don't have a public key and private key you have to have a USB, a USB GPG smart
[11:12.600 --> 11:17.840]  card and Edge will say okay please inject your public key and if you don't have one
[11:17.840 --> 11:22.480]  it will help you to own your USB smart card.
[11:22.480 --> 11:27.080]  Once this is done the public key will be injected inside of the firmware and that permits us
[11:27.080 --> 11:30.640]  like to actually sign the content of slash boot.
[11:30.640 --> 11:34.200]  So here what you see is that it was signed with my key.
[11:34.200 --> 11:37.680]  So all the content of slash boot is verified.
[11:37.680 --> 11:41.560]  The default boot configuration is also signed so it's verified prior of jumping inside
[11:41.560 --> 11:42.560]  of it.
[11:42.560 --> 11:48.240]  So all you see there is the verification of the content prior of trusting it and once
[11:48.240 --> 11:55.360]  this is done it asks us like for the TPM disk unlock key.
[11:55.360 --> 11:59.040]  I think I will cover that later but this is an example of what can happen.
[11:59.040 --> 12:05.200]  Our recent change inside of Edge is that instead of trying to craft a crypt ad entry we extract
[12:05.200 --> 12:08.920]  the NETRD to see what the operating system is trying to do.
[12:08.920 --> 12:13.280]  There's some operating system that we're implementing for some reason two crypt tabs.
[12:13.280 --> 12:18.880]  So instead of trying to craft one we copy like the form of what is expected by the operating
[12:18.880 --> 12:28.280]  system and we just inject inside of it the place where the secret is supposed to be.
[12:28.280 --> 12:32.840]  The TPM will unseal the secret if all the measurements are good so the firmware is good.
[12:32.840 --> 12:36.960]  After that like if the drivers loaded are the same as when we seal the secret inside
[12:36.960 --> 12:42.720]  of it it verifies also that the looks header is exactly the same and if all of those things
[12:42.720 --> 12:45.640]  are as expected.
[12:45.640 --> 12:51.520]  An additional NETRD is created including the crypt padding question and the secret and
[12:51.520 --> 12:58.760]  this is passed to the NETRD of the operating system so we're able to actually boot inside
[12:58.760 --> 13:04.800]  of an operating system without typing your passphrase from a boot prompt that you don't
[13:04.800 --> 13:06.640]  know if you should trust or not.
[13:06.640 --> 13:10.640]  So as it's trustable because everything is measured it has tested to you and then you
[13:10.640 --> 13:14.520]  can type your passphrase there because you're trusting it.
[13:14.520 --> 13:18.400]  So that's basically what we can see.
[13:18.400 --> 13:21.400]  I have laptops here if you want to talk later on.
[13:21.400 --> 13:25.480]  The demo that is there real quick is something that I can launch on my laptop.
[13:25.480 --> 13:31.120]  I acted last week to be able to present it right now but you can have like a flat partition
[13:31.120 --> 13:33.120]  with ESO inside of it.
[13:33.120 --> 13:38.040]  Now you can just say okay media scan you point it like to the partition containing your ESO
[13:38.040 --> 13:39.520]  in question.
[13:39.520 --> 13:42.480]  It will ask you like what ESO you want to boot.
[13:42.480 --> 13:48.880]  It provides like detach signature so basically at that point what you see is again as verifying
[13:48.880 --> 13:56.120]  the ESO with the detach signature that guarantees like the authenticity of the ISO and the integrity.
[13:56.120 --> 14:01.760]  Once that is done it provides you a list of the grub entries that are there.
[14:01.760 --> 14:06.280]  You select it and at that moment like you see the boot options that were passed inside
[14:06.280 --> 14:11.760]  of the grub configuration and at that point a minute later you're inside of tells.
[14:11.760 --> 14:16.920]  So it permits you to actually sign ESO that you did yourself you created yourself any
[14:16.920 --> 14:21.600]  live ESO that you have once you verify it like the integrity of it.
[14:21.600 --> 14:24.800]  You sign it with your key because you already have it and at that point you can guarantee
[14:24.800 --> 14:30.160]  that like a USB drive that you have with multiple ESO will be bootable whenever you want.
[14:30.160 --> 14:34.440]  And in that case it permits you to boot inside of tells and tells guarantees you that micro
[14:34.440 --> 14:36.680]  indemnization will be done.
[14:36.680 --> 14:41.720]  It's in the memory so if you're in an emergency situation or you're in a coffee that you
[14:41.720 --> 14:46.600]  don't trust you remove your battery you work as you want to and at last minute you just
[14:46.600 --> 14:51.280]  unplug your power cable and there's nothing in memory anymore you left no trace you did
[14:51.280 --> 14:53.720]  what you had to do and that's it.
[14:53.720 --> 14:58.280]  That's really important for a lot of customers and this is one of the most important features
[14:58.280 --> 14:59.280]  of ESO.
[14:59.280 --> 15:06.320]  It permits you to guarantee that what you're going to boot inside is going to be as expected.
[15:06.320 --> 15:11.960]  So I covered that already Linux kernel and it contains the standard Linux tools that
[15:11.960 --> 15:18.320]  we need and the policy as well is responsible to fixate the user experience.
[15:18.320 --> 15:21.640]  As a system most of your people are developers.
[15:21.640 --> 15:26.640]  This is a slide pointing exactly in what you should be looking at if you're interested
[15:26.640 --> 15:30.640]  into contributing or customizing it for yourself.
[15:30.640 --> 15:37.440]  One of the good thing that we have right now is that we produce ROMs for the platforms
[15:37.440 --> 15:42.520]  that we support so every time that there's a commit made inside of it Circle CI is actually
[15:42.520 --> 15:47.000]  watching the repository and it builds all the ROMs for all the platform with different
[15:47.000 --> 15:48.240]  cache system and everything.
[15:48.240 --> 15:53.000]  I won't cover that today but this is what is cool like if there is just a change in
[15:53.000 --> 15:59.600]  the policies the ROMs will be created inside of like five minutes if we have cache of what
[15:59.600 --> 16:02.540]  was built before and that's it.
[16:02.540 --> 16:07.560]  It contains the hash as well sorry it's cut at the bottom but each ROM that is produced
[16:07.560 --> 16:13.880]  contains hash of everything that was built and it's supposed to be reproducible.
[16:13.880 --> 16:18.840]  There's funding to make sure that Ed's is backed as being reproducible.
[16:18.840 --> 16:21.440]  Tramil Hudson is helping me on that.
[16:21.440 --> 16:24.640]  It will come in the next year as well.
[16:24.640 --> 16:25.640]  Why Ed's?
[16:25.640 --> 16:29.000]  I think I covered it like already.
[16:29.000 --> 16:37.680]  The main problem that we have like with a proprietary firmware is that there is duplication
[16:37.680 --> 16:40.000]  of code in multiple parts.
[16:40.000 --> 16:44.760]  So we're trying to recreate the wheel and the idea behind Ed's is that we should not
[16:44.760 --> 16:50.360]  do that if we have already a kernel that permits us to drive the hardware that we want.
[16:50.360 --> 16:58.040]  So instead of duplicating at that part here like the drivers to be able to drive the graphics
[16:58.040 --> 17:02.920]  to be able to control your keyboard, the bus and everything the kernel is able to do it
[17:02.920 --> 17:05.600]  and does it like really efficiently.
[17:05.600 --> 17:10.480]  Another reason why we love dealing with the kernel instead is that we can control the
[17:10.480 --> 17:14.760]  IOMMU directly at the moment that the kernel is launched from Coreboot.
[17:14.760 --> 17:19.400]  So at that moment if we specify that we want like to have like the graphic card not having
[17:19.400 --> 17:23.480]  the IOMMU because we're going like to boot inside of Cubes OS for example it can be
[17:23.480 --> 17:28.280]  defined there and it's going to be properly set up for us.
[17:28.280 --> 17:32.280]  Okay, 10 minutes.
[17:32.280 --> 17:35.400]  So again links here if you want to click.
[17:35.400 --> 17:39.160]  The policy that we use as I said is you're in it right now.
[17:39.160 --> 17:46.040]  I will cover that like more in details later on and one of the important change I will
[17:46.040 --> 17:51.240]  cover it like in what is new in the next slide is that we have maximized ROM.
[17:51.240 --> 17:55.760]  Maximized ROM are actually complete, it's a valid complete ROM.
[17:55.760 --> 18:03.360]  It includes Intel ME, it includes an unlike IFD, it includes Coreboot and the packed kernel.
[18:03.360 --> 18:09.960]  So the image that are there inside of CircleCI as artifacts are actually externally flashable.
[18:09.960 --> 18:11.920]  We create like top and bottom image.
[18:11.920 --> 18:17.000]  So if for example the X230 when you open it up there's two SPI chips that you need to
[18:17.000 --> 18:18.880]  reprogram externally.
[18:18.880 --> 18:23.760]  Once that is done you can update internally flash ROM is inside of ads as well so you
[18:23.760 --> 18:29.000]  have control and you're able to like to upgrade as you want.
[18:29.000 --> 18:30.000]  Why ads?
[18:30.000 --> 18:32.400]  There is extensive TPM usage.
[18:32.400 --> 18:42.360]  The reason why we like ads is that there is two sealed secrets inside of the TPM.
[18:42.360 --> 18:46.720]  The first one is happening the first time that you flash your firmware and it's sealing
[18:46.720 --> 18:51.000]  like all the measurements that are created from Coreboot.
[18:51.000 --> 19:00.200]  Coreboot is configured to be in measured boot mode and it extends the TPM PCR to a PCR.
[19:00.200 --> 19:03.640]  Everybody knows what PCRs are in TPM basically.
[19:03.640 --> 19:09.480]  So all the measurements are being done in the PCR2 from the coreboot part.
[19:09.480 --> 19:14.800]  After that when ads start, when the payload is actually loaded which was measured inside
[19:14.800 --> 19:20.920]  of the PCR2, ads extends a couple of other PCRs which are then used to make sure that
[19:20.920 --> 19:26.360]  the integrity of the runtime environment is actually the same as expected.
[19:26.360 --> 19:30.080]  So the first seal secret when you flash your firmware, the next time you're going to reboot
[19:30.080 --> 19:36.160]  it, ads will say okay you either don't own the TPM so you have to own it or otherwise
[19:36.160 --> 19:41.120]  it will say okay we have a couple of measurements that were provided by Coreboot in measured
[19:41.120 --> 19:43.400]  boot mode so we have to seal them.
[19:43.400 --> 19:47.960]  When you seal them, it will create a QR code which you can scan on your phone or if you
[19:47.960 --> 19:55.040]  have like a NitroKey Pro or a LibreM key and you use like the HTTP version of the firmware,
[19:55.040 --> 20:00.860]  it will ask you to seal that secret as well inside of your USB security download.
[20:00.860 --> 20:10.760]  So at that point you have the measurements of the PCR4, 5, no it's another slide, sorry,
[20:10.760 --> 20:12.560]  no it's not another slide.
[20:12.560 --> 20:20.720]  So basically you have like the measurements of PCR0, 1, 2, 3 and 4 that will be like inside
[20:20.720 --> 20:25.840]  of the first sealed secret which guarantees like the attestation of the firmware.
[20:25.840 --> 20:30.360]  So you boot your machine, you plug your USB key, it will flash green if the measurements
[20:30.360 --> 20:35.720]  are good from the firmware alone and after that if you set a default boot configuration
[20:35.720 --> 20:42.200]  you're actually using all the other PCR measurements to seal the secret plus the lux header that
[20:42.200 --> 20:48.760]  is extracted because we have Crip setup and you're going to seal it with a passphrase
[20:48.760 --> 20:52.240]  that you define at that moment, at the moment of sealing the secret.
[20:52.240 --> 20:56.640]  So when you're booting, it's what I showed you before like in the other screen that was
[20:56.640 --> 21:05.040]  here, when it's asking you to type your passphrase it's making sure that all the measurements
[21:05.040 --> 21:10.380]  of the PCRs are exactly the same in an attempt of unsealing the secret inside of the TPM.
[21:10.380 --> 21:15.000]  So at that point either if your password is bad or the measurements are bad as we'll
[21:15.000 --> 21:19.560]  just refuse to boot your system and it will say to you PCR mismatch and at that point
[21:19.560 --> 21:22.680]  you should be worried and investigate.
[21:22.680 --> 21:26.480]  So that's it for that.
[21:26.480 --> 21:27.720]  Why is it important?
[21:27.720 --> 21:33.080]  Because yeah, the secrets that are sealed inside of the TPM memory are actually making
[21:33.080 --> 21:38.280]  you sure that you're in the state that you expect prior of typing a passphrase.
[21:38.280 --> 21:43.720]  For use of typing passphrase in weird environment, this is an environment that is trusted.
[21:43.720 --> 21:48.240]  So at that point like anything that you do inside of eds and that opens the door like
[21:48.240 --> 21:53.220]  to add more feature will work as defined.
[21:53.220 --> 21:56.840]  I will go faster because I have only five minutes.
[21:56.840 --> 22:02.560]  The reason why maximize boards are important is actually that on an OEM version of the
[22:02.560 --> 22:04.840]  firmware this is what we have.
[22:04.840 --> 22:10.960]  The Intel IFD is locked, the IFD is basically the description of the region inside of the
[22:10.960 --> 22:16.960]  firmware as defined there and ME is also locked.
[22:16.960 --> 22:21.200]  So if you want to take advantage of all the firmware space that is there to add tools
[22:21.200 --> 22:24.400]  you have to unlock the IFD and you have to unlock ME.
[22:24.400 --> 22:30.400]  So the reason why the maximized, this is a configuration of the maximized board.
[22:30.400 --> 22:34.320]  This is the extraction that we have here of the important part.
[22:34.320 --> 22:39.000]  So flash run here like on the legacy board or if you're coming from Ivy Rain for those
[22:39.000 --> 22:43.600]  who are interested in that project is that you can only flash the bias region.
[22:43.600 --> 22:50.080]  And the bias region is only having eight megabytes by default on the legacy or the OEM version.
[22:50.080 --> 22:56.800]  So if we externally flash and we nerter ME we're getting more than four megabytes additional.
[22:56.800 --> 23:03.880]  So if we add that inside of the bias region we're having like 11.5 or nearly 12 megabytes
[23:03.880 --> 23:09.320]  of usable space where we can add more features, we could even add Python there if we wanted
[23:09.320 --> 23:12.520]  which is something that I want for a really long time.
[23:12.520 --> 23:15.520]  So this is what it looks when it's modified.
[23:15.520 --> 23:20.920]  Actually you see that the bias region is equivalent like of XBE for FFF so basically
[23:20.920 --> 23:24.080]  it's near of 12 megabytes.
[23:24.080 --> 23:27.160]  Yeah, I covered that.
[23:27.160 --> 23:33.800]  Actually the reason why we love it for the redistribution, the issue that we have on
[23:33.800 --> 23:38.920]  blood redistribution is that inside of the edge repo we owe the scripts.
[23:38.920 --> 23:44.880]  The scripts are being called by circle CEI to actually download the images from Lenovo.
[23:44.880 --> 23:47.360]  We extract them directly on the CEI.
[23:47.360 --> 23:49.200]  We're able to extract ME from there.
[23:49.200 --> 23:51.920]  We're able to nerter ME from there.
[23:51.920 --> 23:58.160]  Then circle CEI is responsible to build Corgut, use the module that we're extracted, validated
[23:58.160 --> 24:02.120]  and everything and from that moment we're able like from a simple script like that
[24:02.120 --> 24:07.640]  to build a complete run image and we just dodge the legal issues.
[24:07.640 --> 24:15.320]  So whatever circle CEI is building like that, I gave it as an example here, provides like
[24:15.320 --> 24:18.120]  artifacts.
[24:18.120 --> 24:20.520]  This is a build from circle CEI.
[24:20.520 --> 24:24.720]  This is like the output of Corgut which was able to stitch everything together and at
[24:24.720 --> 24:27.520]  the end of the build and you have the image I was talking about.
[24:27.520 --> 24:32.560]  So you have the 12 megabyte full image that is internally flashable and you have two image
[24:32.560 --> 24:37.960]  for each commit which are there provided by the circle CEI for 30 days after the moment
[24:37.960 --> 24:39.880]  of the build.
[24:39.880 --> 24:44.400]  That permits you to externally flash and then it permits you to internally flash forever
[24:44.400 --> 24:48.040]  after.
[24:48.040 --> 24:51.160]  The OEM way is like that, yeah sorry.
[24:51.160 --> 24:56.440]  The WipTel support is for either servers and BMC.
[24:56.440 --> 25:00.200]  So it would be usable on the KGP D16.
[25:00.200 --> 25:03.680]  This is what it would look like from a remote serial connection.
[25:03.680 --> 25:09.600]  So if you're connected on the BMC remotely, this is exactly what you would see.
[25:09.600 --> 25:15.800]  The HOTP card dongle could be in your server and the TOTP is what you could check remotely
[25:15.800 --> 25:20.080]  if the time is good and then you have the same option but console based.
[25:20.080 --> 25:26.720]  This is what we see if we're having graphical frame buffer on laptops and desktop.
[25:26.720 --> 25:33.120]  The OEM factory reset, OEM factory reset with ownership wizard was upstream.
[25:33.120 --> 25:37.800]  So it looks like that asking you like to what you want to do, giving you options that are
[25:37.800 --> 25:42.200]  really important if it's not you who have installed your operating system.
[25:42.200 --> 25:47.080]  This is what I pushed forward because if you don't install your operating system yourself
[25:47.080 --> 25:52.520]  then the LUX encryption key could be intercepted.
[25:52.520 --> 25:56.440]  So you want to re-include the content of your drive and once again, since we have Linux,
[25:56.440 --> 25:59.360]  we can do that directly inside of it.
[25:59.360 --> 26:01.200]  You will have like to look at that for yourself.
[26:01.200 --> 26:05.400]  I won't have time to cover that but this is what it is and the main thing that is really
[26:05.400 --> 26:12.680]  nice for developers is that we now have QMU and QVM boards with software TPM support.
[26:12.680 --> 26:19.600]  So all the images, mostly all of the images that I provided were taken from the QMU version.
[26:19.600 --> 26:21.880]  This is what it looks like when you build it.
[26:21.880 --> 26:25.320]  So you can inject your key and then after that you can run it.
[26:25.320 --> 26:30.640]  That's how it looks and then you can add your recovery shell directly from the terminal
[26:30.640 --> 26:36.560]  and you will see the output of WipTel and you can develop and test as you go.
[26:36.560 --> 26:37.560]  And this is what's next.
[26:37.560 --> 26:43.000]  I'm sorry I won't be able to cover it directly but I gave link on everything that the work
[26:43.000 --> 26:44.000]  is happening right now.
[26:44.000 --> 26:48.520]  TPM 2 support is coming so new boards will be able to have it.
[26:48.520 --> 26:54.000]  Cleanroom GPT key generation is the next thing I'm working on to be able to remove the need
[26:54.000 --> 26:58.360]  of having your USB security dongle because people want to test it but don't necessarily
[26:58.360 --> 27:02.320]  want to buy any Trukey which was a problem before.
[27:02.320 --> 27:07.440]  Write protection is coming so if you want to look at this and poke me there or any question,
[27:07.440 --> 27:10.360]  SPI write protection was developed by 3MDeb.
[27:10.360 --> 27:15.760]  It is now in the PR that is supposed to be merged in the next couple of days when I will
[27:15.760 --> 27:17.440]  have a time.
[27:17.440 --> 27:20.960]  International keyboard support will come because right now it's just US keyboard which is a
[27:20.960 --> 27:26.520]  problem for a lot of people and randomization of the mic address will be possible directly
[27:26.520 --> 27:31.160]  in the GBE partition inside of ELS and being reflashed.
[27:31.160 --> 27:35.760]  And this is it folks, reference.
[27:35.760 --> 27:42.480]  I really recommend to watch the original talk on ELS if you have like more in-depth questions
[27:42.480 --> 27:51.680]  because the background didn't change and that's it, thank you.
[27:51.680 --> 27:56.800]  Do we have time for questions?
[27:56.800 --> 27:57.800]  Okay.
[27:57.800 --> 27:58.800]  Yes.
[27:58.800 --> 28:13.800]  You mentioned support for TALUS board PC systems, how do you support them since they
[28:13.800 --> 28:16.600]  don't have TKM?
[28:16.600 --> 28:19.360]  You said the TALUS 2 platform supported?
[28:19.360 --> 28:22.960]  The Raptor, yeah.
[28:22.960 --> 28:27.680]  The question is does the TALUS 2 have a TPM chip?
[28:27.680 --> 28:31.720]  There was a connector that was a really big adventure, I will try to make it really short.
[28:31.720 --> 28:36.520]  The port was done like with 3MDeb here and actually there is a TPM connector but it was
[28:36.520 --> 28:38.640]  not working properly.
[28:38.640 --> 28:45.400]  So we had like to do research to be able to actually make it work on the panel but yes,
[28:45.400 --> 28:50.480]  there's no TPM inside because it's against their mentality but you can connect one but
[28:50.480 --> 28:56.200]  it will be the one that you buy from 3MDeb because you have to add a TPM chip.
[28:56.200 --> 29:00.600]  You have to add a TPM chip but it's available from their shop, so yeah.
[29:00.600 --> 29:01.600]  Another question, yeah.
[29:01.600 --> 29:06.400]  Do you do remote attestation if you don't or are you interested in it?
[29:06.400 --> 29:10.720]  It's something that I don't have, oh yeah, do you do remote attestation?
[29:10.720 --> 29:16.520]  Actually VaultBoot did it, VaultBoot is actually a fork of ads.
[29:16.520 --> 29:21.600]  I'm looking into upstreaming the code but I would say that any person that is interested
[29:21.600 --> 29:26.600]  into that kind of feature, I would guide you to see what they did because they have a proof
[29:26.600 --> 29:32.840]  of concept that is really interesting on the Raspberry Pi for remote attestation and there
[29:32.840 --> 29:36.360]  was a board config for Coreboot there as well and everything is there.
[29:36.360 --> 29:41.960]  It's just a trying to upstream but I'm not against it but ads as of right now is more
[29:41.960 --> 29:47.680]  targeting users to actually own and being able to verify for themself but remote attestation.
[29:47.680 --> 30:05.080]  So the question here would be like is remote attestation possible, yes, someone is suggesting
[30:05.080 --> 30:10.440]  to do it like remotely on the phone, it would be totally possible, there's no, please contact
[30:10.440 --> 30:12.560]  me, okay, cool.
[30:12.560 --> 30:16.720]  Another question maybe, no?
[30:16.720 --> 30:22.240]  Sorry for this dense presentation, next presentation I will be better.
[30:22.240 --> 30:23.240]  Thank you everybody.
[30:23.240 --> 30:35.360]  Thank you very much.