I'm here today to represent a completely different talk normally from Firmware.
I mean, I'm probably some people know me from the Firmware world, so I did a lot of open
source Firmware stuff.
But like there was another topic on the CFP was TPM in attestation and I thought like,
okay, we had to start up for three years, it failed, but we built an attestation product.
So I thought like, okay, let's make it open source.
So my co-founder Kai is here as well.
And so we thought like we just make it public and probably also like integrated and some
other stuff.
So I'm giving today a presentation about it.
I first thought I give you a lot of insights and architectural information, but we worked
with three people on that for three years.
Yes, plenty of code.
So I decided not to use that.
So I just give you today a high level overview.
But if you're interested, you can just go to GitHub and look at the project.
So yeah, streamlining boot and kernel security in the cloud is basically the topic I hope.
Oh, sorry, I hope it works.
Sorry.
Ah, no, it works.
So who I am.
Yeah, I'm now a consultant.
I'm doing a lot of firmware and like firmware security and trusted computing stuff.
I also did a lot of open source firmware.
Can see me with some Facebook servers there.
I'm holding.
Yeah, and I did a three year startup journey at Immune that was unfortunately directly
in COVID.
And so that wasn't that great, but I can share some information about the journey in terms
of attestation and TPMs.
And we also like have a booth at open source, you know, foundation booth at K2.
So if you want to come over to talk a bit more, I would just leave after this to just
go to the booth to talk to the people.
So feel free.
I worked a lot of open source projects.
Yeah.
So the story at all in total is that we had the startup.
We built a SAS product like like all these startups do, right?
And so the idea was basically you do endpoint security with this product.
And what we wanted to achieve is basically one secure endpoint systems like Linux, Windows
systems securing them with an additional layer of security for specific type of attacks.
So that was our goal.
And it should like be integrated with the standard endpoint protection mechanism of nowadays
like most of the Windows guys probably use endpoint protection like antivirus, what Windows
defender, whatever is built in.
But the Linux guys for sure have also other stuff like integrity measurement architecture,
it's more open things.
And so that's great.
So we built this type of SAS, which gives you observability.
And yeah, what does it do?
Yeah, basically it protects everything from the power on over the security configuration
over the firmware itself.
So there we come back to the firmware topic.
We also protect the boot loader, the operating system and the drivers.
And we also protect the endpoint protection or EDR.
That's really business words, but let's say you can have that on Linux with open source
stuff.
So that's what is possible.
So if you ask Chattivity nowadays, what does the malware first do if you have a system
and it invades the system through an exploit or whatever, it will basically try to hide
itself if possible from the antivirus or whatever kind of detection software protection
software is there, or it will try to disable the antivirus.
So that is the most common thing.
So nowadays they really kill off all this snake oil stuff.
And so what we try to build is something much better than that.
So for that we can look at the problem at the moment.
So there were a lot of attacks in the 2000, 2016, which basically targeted apps and a
little bit of hypervisor.
But nowadays the attacks going to more into the firmware direction.
And the reason for that is basically that there is a lot of growth inside the firmware
ecosystem.
So for example, we had in 2000, I think 32 kilobytes or 64 kilobytes of firmware, probably
a little bit more on some systems.
But nowadays we have 64 megabytes on a laptop.
This laptop probably comes with still 32, but the newer one and there's other Thunderbolt
firmware and other of other things.
There's tons of attack surface on the firmware level now.
And so that means companies like Dell start to make cloud services for their BIOS.
So they attach the BIOS to the cloud.
And that was quite prominent.
It was, I think, in 2021 summer.
And it was super fun because what basically happened here is that they had a TLS connection
into the FI itself.
And the certificate, the PKI was broken for whatever that was like a bug.
So you could basically hijack 30 million devices over the internet.
That's kind of funny.
And the funny part is if you do that over the firmware, you have full access on everything.
No hypervisor, no antivirus, nothing will protect you from that.
So that's really crazy.
And I mean, this you have also on Linux systems.
It's not like it's disabled.
It's there.
You just don't know.
And so we thought we need to close somehow the security gap from hardware firmware to
hypervisor operating system core.
Because apps protected nowadays with tons of security mechanism in Linux as well to do
that even if you use proprietary software.
You can just do open source things to do that.
You can just go to any security conference for Linux and check that out.
But that's easy.
It's already solved.
It's starting to get solved.
This is like, that's easy.
So we try to do the hard thing.
So how do we do that securely?
How do we really make sure that the attacker is not disabling us, right?
Because it didn't disable any other type of antivirus.
So what we try to do then is we want to use the security chip.
So there are a lot of security chip nowadays out there, especially in the server ecosystem,
but also on laptops like these ones.
Either they are in firmware or they are in real dedicated hardware.
Or they come as part of the system on ship.
So the processor itself.
And the most prominent one is the TPM2, which is now everywhere in every laptop.
So probably every one of you has at least the TPM2.
Or if you have a MacBook, you have a security chip, it's not the TPM, but there's a chip
security chip.
So everything is there.
And so we have that TPM stuff quite long.
It's everywhere.
You can also have that in data center devices.
And so what we did now is basically we built a product where you have like as us, you have
the security operation center and they do insight and remediation.
And then you have the employee laptops.
I mean, in the open source world, you probably have like your own fleet you want to manage,
and then you have like some kind of monitoring tool, a monitoring system which tells you
what's going on and then you can act if something happens on your system.
That's what you want to do because you never know what happens.
Because there can be vulnerabilities you don't know.
They're all talking about risk mitigation, but the reality is even with all the known
risk, there are tons of unknown risk.
So this is difficult.
So how do we do that in detail?
I try to not to explain it too deep completely.
So what we use is the TPM chip.
It has a secure credential storage.
It's basically on the most of the devices and we do remote attestation.
Remote attestation is basically the idea of asking the TPM chip, give me the state of
this platform.
And that's what we're doing.
So we ask the TPM chip, give me the state of the platform and thanks to the current
situation in the firmware world, it gives you the state of the platform in a specific
type of let's say artificial binary blob which is signed, which is publicly parsable.
You can write a parser for that.
There are tons of parsers out there already.
And it's signed.
It has the timestamp and the nonce.
It has all the hashes of the executed code down to the, at the moment for Linux, it's
down to the Linux kernel.
And from there, if you start the integrity measurement architecture, they are like, it's
enabled in all distros.
You can just enable that and it hashes everything which has been executed.
You can also write a policy for that technology stack.
It's more like an endpoint protection replacement for Linux.
So it's kind of super interesting.
Most people don't know.
There you Ubuntu, Fedora, whatever is able to do that.
You just need to place a configuration thanks to system D and Linux.
For doing that, so super easy.
Anyway, and so what we do then is we gaze all this information with the open source
tool.
This open source tool is basically gazing information, putting that into the attestation,
signing everything, making everything super secure.
You can even bind the TLS keys for the encryption and everything to the TPM.
So it basically is secured also over the TPM.
So everything is clear.
It's also clear.
The platform is identifiable.
And then we send everything back to the cloud and do our crazy cloud analysis with our
check engine.
That's what we basically do.
Quite similar to a normal endpoint protection, except that we do tofu.
We don't do like what they do is like they try to find specific patterns for more.
What we do is we check if this is a legumintate action by having smart decision tree to say,
okay, this change in array where we know this can be secure.
And thanks to this architecture is quite fine granular.
That means we can do it quite deep and in a good way.
So how does it look like?
So if you run our software, you can find now on GitHub, you basically have a dashboard.
It looks like that with all the risk and incidents.
This is all like more business like, but we sort like customer wants to buy it, right?
It needs to look like shiny, not like there's another project called KeyLime.
It's also nice.
They are more focused on container for attestation, but they do it with less good UI stuff.
So we try to have a really big focus on UI and that was kind of super important for us.
And so what we built in as key features is basically the secure device identification.
We can identify the device securely.
We know the integrity of all the software components.
We execute until the endpoint protection or the kernel takes off with that drivers.
And we have also the secure monitoring which runs all the time, right, remotely.
And you can just like build that into your data center operation or whatever.
You can even do it on endpoint operation.
And so additionally to that, we gained storing credentials in HATRA and the trust income.
You can additionally, we didn't do that, but you can also like push credentials to the platform for VPN and other stuff.
That would be the next step in the future.
And also access revocation by incident.
So then you can, okay, 10 minutes left, but I'm already quite far.
So yeah, the incidents, if you run the system because it's super complex,
that's why I didn't want to explain it in detail because it's like a lot of code and everything.
It's basically giving a list of incidents on multiple affected devices.
And there you can see specific type of incidents.
It has documentation for all this type of incidents.
You can check it out.
You can extend it.
You can improve it, whatever.
If you want to work with a project, it's super.
We are quite open for contributions.
So and it has also an extended feature list, which is quite, yeah, let's say it was quite experimenterial because we are start-ups.
So we tried out a lot.
So we added entity to support.
This is for, so in order to make really that the firmware is coming from the vendor,
you can have some service from Intel to verify that.
And we added the service that's there.
And then there's, finally, it's there famous for firmware vulnerabilities.
We did the scan over the firmware as well.
So we extracted the firmware from the system, put that in the data we sent to the, to the analyst system.
And then we could also find their vulnerabilities and everything.
We added LVFS integration, which was kind of nice because then you can check also for firmware which is there in LVFS and check if hashes matches up.
And if it's the same, because the biggest problem of all this attestation story is basically the firmware.
But still it's got much, much better than before years ago.
I did it like 15 years ago.
It was horrible because the firmware implementation were all buggy.
And now we have UFI.
I don't like it, but it's much better than what BIOS provides in terms of security.
And so the hashes are somehow can be pre-calculated.
You can evaluate them and say, okay, this change or that's changed, right?
So that's the only important thing.
You want to know what changed basically by seeing the hash and having additional information.
We have built an engine for doing all this checks.
This is like trust on first use.
So the first time you install it, it's basically then trusted.
And when something then changes, it's tried to automatically evaluate.
This is like the PCS is a hashes basically platform configuration.
We just check it up and looks and sees, okay, this change, for example, the bootloader changed and specifically the hash of the certificate changed.
And we know, okay, this certificate changed.
And this is normally a sign, for example, for an attack because if you have a bootloader and it's updated, it's super rare that the 10 years valid certificate changes, right?
So you can add additional checks to the engine.
You have also a wireless engine.
So if something you won't really allow, you can just accept and then it's like, it's a trust-based then or the trusted computing-based.
And we also have risk detection protected by the attestation.
That's also part of it.
And there's a nice view for incident-risk and device views.
It looks like this for a single laptop.
So you can see it, for example, for my Lenovo SyncPad X1 Carbon.
And you can basically see what kind of device integrals stepped past and where it stopped.
So that's what we did.
So we could see from the supply chain to the device configuration overhost firmware bootloader operating system and to the endpoint protection.
So you could directly see what's going on.
And if you like, here you can see this in all the picture, but you basically could like open it up and then you see a lot of detail what happens there.
So you can see, okay, this hash of this file changed with this certificate and whatever.
And so you can investigate that.
Additionally for security stuff, if someone just wants to use the code or get some insight, we opened up CME into CME measurements, which wasn't public yet.
There's RIM certificate support.
This is like for the TPM RIM certificate, for the supply chain security stuff.
Current drivers for firmware extraction for Linux and Windows.
Then we added IMA support similar to KeyLine and AZ support, as it's an antivirus.
And for Windows, generic endpoint protection support.
So you can also use it with any generic endpoint protection.
Mostly we tested it on Windows Defender.
We added Intel ME API support.
It's like the management engine of Intel.
We can talk with it and find a lot of information out there.
It's super helpful.
So if you need code there, just grab it.
And we can also verify the TPM itself that is coming from the vendor and not like someone exchange the TPM or whatever and try to take the system.
So you could download that for Ubuntu Fedora and generic Linux and Windows.
And then there's an OS open source agent.
It's more like a tool you can just install with the system descript.
Execute that and this one gives us the data.
It has really low memory footprint, so it just runs every one minute you can say and delivers the information.
Push only to the system, which is kind of good because we don't have a back channel executing stuff on the system.
There's another security hole.
So it's super easy to use.
Yeah, and that's also available.
How long?
Still five minutes?
Okay.
Thank you.
And yeah, this is a repository.
You can find it on GitHub.
We probably move it maybe under another org or we maybe keep it.
I'm not sure, but you can find it now there and feel free to check it out.
This is BSC licensed.
So everyone can use it and build also products from it.
What I want to do the next few months is that I want to do more code cleanup.
I've already thrown out a lot of stuff, but we still have some leftovers,
especially for business features and so on for accounting and all this nonsense and no one needs.
So I'm just ripping that out and adding CI support,
pre-built releases for Windows and Linux so you can just install it directly on the system
and ease up the deployment because currently it's there's an instruction to do so,
but it's like super complicated stuff is Kubernetes and all those things.
Maybe we can make it a little bit easier and there might be other features where we can integrate it directly into system D and other stuff.
So yeah, that's basically the idea.
And now I have a demo.
I hope it works.
Please work.
So I can probably, can I?
Yeah, we have.
Can we make it with sound?
No, I don't need.
I explain.
So this is Windows 11 with all security features on all this super crazy Windows 11 stuff you can know from Microsoft and their marketing.
And then we are in our tool here, right?
It's just like, it's a little bit like probably that could be also done better instead of tokens.
But anyway, we just like bind this system to our system and it installs it and takes a while when it's done.
Come on.
Okay.
So and then on some points the device shows up.
It takes a while.
But of course the engine needs to like analyze it and then it's trust on first use.
Basically it's protected.
And this demo is based on Black Lotus malware.
So I got Black Lotus malware.
So we won and tried it out.
And the funny part is, so what you can see in a few minutes is basically that you install Black Lotus and Microsoft doesn't.
So they know the signature because I didn't repackage it.
So that's what you normally do with malware.
So they can check the signature anymore.
And so, but you can see that I execute the malware.
Then the anti-rials saying, yeah, I know the signature because it's known, but this is quite easy to fix.
But I didn't do that for the demo anyway, because I don't want to to mess around with packaging P32 binaries.
Anyway, and then I just executed on the system.
And what happens is that it over overwrites a bootloader which is before Windows and injects code into the kernel and turns off all security.
But everything in terms of endpoint protection after the reboot tells you everything is fine.
And if you looked in the detailed information, see all the security what they built is completely disabled.
So that means attacks going into the deeper level are not covered by Windows.
They cannot be protected with all their security stack.
And so our system basically detected the malware, as you can see with the red information, the bootloader manipulated.
And then it takes a while until Microsoft gets, I don't know what it does there.
Like I'm a Linux user, but this thing shows in few seconds that everything in terms like secure.
Oh yeah, now it shows nothing, right?
And then you go to details like advanced protection or whatever.
And then yeah, everything's turned off.
So yeah, that's how it goes.
That was my presentation.
Thanks for listening.
Oh yeah, say it's all I have to return to.
But anyway, that's it.
So any questions?
I hope I have some time.
Yeah.
My question is you are mostly focused on malware type of attack.
But could this software somehow prevent an attacker with a physical access?
Like if someone manipulates my laptop, for example, if you could temporarily disconnect TPM in boot
and you could install this malicious bootloader.
So you disconnect the TPM, you boot the malicious code and then you submit all the right hashes.
And you pretend TPM seems that it's a valid right.
We cannot protect against bus attacks on the TPM.
I mean, this is like hardware attacks.
You cannot do anything against hardware attacks.
There's no real security against hardware attacks.
Even in a confidential computing environment, side channel attacks and what power glitching attacks and all this stuff is always possible.
So we don't say we can protect against hardware attacks.
We can probably detect like if you plug in in USB stick, right?
If you try to execute something else or if you try to modify things on the system, that's what we can detect.
But we are not like claiming that we can really do it low level on the bus system.
I think you can provide that by there's like a way to authenticate the TPM.
So you can have an authenticated session which is encrypted and then you cannot do this type of attack anymore.
But that's what is currently missing.
I think in the goal in TPM library.
But yeah.
And then Oscar.
Yeah.
Please repeat the questions because you know, oh yeah, sorry.
I'm sorry.
Yeah.
Okay.
So from your previous question, I think we can also protect from supply channel attacks.
Right?
We can.
So what, so if you can, can we protect against supply channel attacks?
We cannot completely protect against it, but we can probably detect modification on the firmware side.
It's because there's also signature verification and this is all measured.
So you can do that.
What you can also do is to detect if the TPM is the same TPM and if it's really a TPM from the vendor.
This is also possible.
But yeah, sure, there are limitations in the threat model.
But I think that's a good trade off.
I mean, for me, it doesn't have to be perfectly secure.
But yeah, probably we could extend it, make it better, improve it.
But yeah, that's the current state.
Yeah, some of these questions are like, security is a binary state.
Security is not a binary state.
It's a spectrum which we kind of travel and we can be either, and it depends how much we have, we can lose, how much we can pay for that, then that much we can do.
Yeah.
That's what I think also security is not a binary state.
Not zero and one.
It's somewhere in between, unfortunately.
Yeah.
I have a question.
You mentioned your presentation here.
Do you plan to cooperate with the TPM support?
So if you can at the TPM support depends or if we cooperate with the TPM project depends on like, we are open source project, right?
If we can like support that, why not?
If someone makes a pull request, feel free to do so.
We will just integrate it, right?
So there's no reason why we shouldn't integrate that.
I think I just want to have the three years of work we made, not completely a loss.
So sure, probably it's not taking off as open source project, but that's always how it is.
But we thought like it may help some people and give them some more insight what we did.
And yeah, maybe they can reuse that for business or for personal reasons.
So malicious agent attacks, this is a good question.
So the problem is with the TPM, you cannot forge the stuff from the TPM itself.
And since the quoted data basically has a nonce and timestamp and everything, you can forge it.
That means the agent can definitely try to connect to our system,
but if we don't get the blob, we don't talk with the agent anymore.
So this is like, sure, you can say we don't talk back to the system.
That's one option you just completely go silent, but we have for like a counter and there if it's 50-minute over whatever
or like specific amount of time, it doesn't call back to us.
Then we say the system is unknown state.
So I mean, that's a trade off attestation, but I think it's fine.
Yeah?
If anyone is interested in TPM hardware attacks,
stack smashing just post that thing doing that in like a minute,
one of the actual carbon.
So just put a snap for hardware on top of the TPM stuff and there you go.
But yeah, part of the protect against it.
Yeah.
So we did it for more of their protection basically.
That's software-based attacks mostly.
But if you can detect it, at some point, and somebody is sniffing something,
and you can somehow detect that, you can do something like wipe remotely or whatever, right?
So all data doesn't bring up too much.
Yeah. That's true.
Especially with the carbon that automatically unbox.
So that just happens because some other passions match,
and then later you will be aware that we give you a scenario.
Yeah. Any other question or anything we have done?
I don't want to play more time here.
Thank you very much.