 Hi everyone, my name is Chris and I got my friend Philip with me. Hey, hi and Yeah, today we like to talk about demystify into security technologies in fiambo. Yeah Unfortunately, we are not able to Preval to the US so We have to actually do our Recording here and be there remotely All right Yeah demystifying into security technologies first of all, I'd like to give us like a short intro on who we are and what we're doing So we are both working at nine elements, right nine elements is the largest open source Independent bios vendors so IBV worldwide We are more than 12 30 15 people now And only work with open source firmware We're actually driving the open source firmware community So we founded our own Conferences we are in the leadership meetings of Corbwood Linux boot yana core and all the other Firmware projects which are out there. We will not go into these projects today Or not that much actually, but just so you know, what our background is here Yeah, what do we want to talk about today? So today it's a little bit. Yeah, it's a firmware talk obviously, right? And here where as you might know and probably you know best That fear was quite blocked today, right? So there's like a lot of blocks and binaries all over the place and It's also NDA like a lot, right? So for everything that you that happens in firmware like every security technology and also everything else basically You need an NDA with one of the big stock vendors to actually get documentation if there's any or to get to link if there's any and yeah As I said firmware bios in UFI is it's it's pretty blocked. There are a lot of binaries to give you an example Like the normal x86 x86 firmware that you have have nowadays. I mean what what blocks do you have there? There's like a handful of CPU vendor blocks like all these famous support packages that you actually need to do all the memory in it The silicon stuff and so on There are also additional OEM and ODM blocks like for custom custom stuff that they actually put in there for for a graphics card and all these kind of things right and All together that's like if you have you know, like a 16 MB firmware image It's at least half of the images. Yeah, at least 10 megabytes. I would say so on a modern Platform at some moment. Yeah, so that's that's even more than half right? Yeah, I mean, I already got my new Lenovo X1 Carbon Gen 9 and it already has inside the Linux six firmware blocks for initializing audio and Video and whatever so it's like it's really it's really not really nice and so we're seeing more blobs in the ecosystem now and Actually, I mean you have 10 MB of blocks, right and the other six MB is close source firmware Everything is actually close However, the blobs are even even even more special, right? Yeah That's true. Yeah And also, I mean the other the one thing is we have firmware and all the blobs inside and the other thing is There's no real tooling right for these kind of things. I mean, there is some tooling And also some open source tooling some close source tooling most of the close source to makes actually only run on windows and these kind of things, right? So there's no really open source tooling for for these kind of things out there And I think that is that is was one of our main Main motivations here actually to do what we did in the last few years and also for Transparent security out it. It's really important to have let's say open tooling or at least open documentation about those technologies, right? How do you an open and transparent security out it if you don't know what's in there? So it's nearly impossible. Yeah, that's a huge problem actually hmm, I mean nowadays if we look I mean we in the stock actually now We're concentrated on Intel but not that AMD is much better on that part But we're concentrating on Intel and there are so many security technologies in it, right? I mean, I know hands full like out of out of my mind, right? It's like pvr SGX TDX There's bootguards. There's txt. There's some CVT What what did I miss? There's probably STM right secure transfer. Oh, yeah, yeah, right It's it's and there are also some hidden ones which are not public yet So we can just close them but there are tons of more inter security technologies out there Probably you had some and you had some of them we currently have in the slides But in general, this is it's a really it's a jungle of IT security technologies Yeah, and what all of them have like fancy names, right? And you don't really know what they're doing And the thing is most of it, right? Most of them are actually implemented in firmware or if not any of these right so at least any of the ones that we named by now You have either any binaries or structures or functionalities and even SGX right so secure software guard extension abase it basically They have also firm as the most people don't know but it's located inside the microcode So even if you have like confidential computing technologies, they also need them Probably the firmware code is really small and it doesn't compare with which with other parts parts of the system But yeah, that's it's really yeah. Yeah, and I think that's that's unknown to most of the people, right? So that that you have so that these security technology actually like so much on firmware And even if you're an IBV as as we are even then these parts are in the eight right so we have to have special MBAs with the sock vendors and so on to actually get proper documentation on these kind of things and Like to be honest even with proper documentation most of the time. I know it's trying error, right? So that's that's the thing Yeah, so What what does that mean, right? So everything is implemented in firmware You're actually relying on on the OEM or OEM to that they know what they're doing, right? And that they provision your platform correctly that they configure your platform correctly and these kind of things and and that is Yeah, that's like a big risk here, right? Yeah, and also it's impossible to to get into that topic quite easily If you're part of the linux community, right? So as there might be some public documentation now But it's just high level. It's no details in it and all the edge cases and problems in these technologies are not documented and So this is a really a problem. No, there it is Yeah, so and that's that's where it all starts basically, right? So we will give now an intro to the Intel convert security strategy, let's say so convert security is basically the idea of Putting everything together, which basically means if you have security technology It always has a core root of trust and this core root of trust somehow Can be shared between different security technologies, right? So and even if you're a hardware vendor It's really expensive to develop everything every new technology and a new stack So it's probably a better idea to base it on one stack you have in control And so we will talk about it's not it makes sense, right? At least make sense. I just okay Let's share some of these features across the different technologies that way is that's It's also better for security, right? Because you only need to verify one one Caustic let's say in terms of security properties. No, yeah But let's say Intel started that and they call it convert security strategy and at the moment It includes boot guard technology will become later to that extended to the use the same for trust execution technology And into PFR All those technologies are currently in there I heard there will be more coming which merge in so they try to add more and more security technology or put it on top of their core technology stack and So we will see what happens in the future in the next generations. No, but this will definitely happen Yeah, I mean book guard and txt. I think they called Converged guard and txt, right? Yeah, yeah, but people come later to that We first we will explain basically the core technology concept So we had come as this off. So basically in the technology concept. We have four four things So we have the Intel authenticated cold modules. You may have May have heard about this is some kind of block, which is doing all those security stuff There's a CPU which is really important in this case A result would be bad the internet management engine so internet management in the for everyone doesn't know what it is It's basically the Southbridge. Yeah, it's Southbridge. We have this benefits. I call it's like that's solid benefits And we have PMV security headers, so we have some kind of headers around the bios or your five PMV So first we will look into the ACM So ACM are basically closed source binaries or firmware Distributed by Intel They're basically written in assembly. I don't think they use C rates So most of our biggest part of it is probably written assembly may might be some C Maybe they use some C for it as well But they are really low level because they run before the memories initialized inside the CPU cache Yeah, and actually you don't have much there right before you got DRAM Like you got the CPU cache basically right like there's a couple of things going on But there's not much that you can actually do there. Yeah, and the the the the nice things actually so Before you so when you turn on your computer basically and before the x86 system x86 firmware actually starts The CPU loads these ACMs, right these authentic code code modules into its own Let's call it RAM. I think they call it AC RAM, right? So they have like a special proposed RAM or I think they're using the cache basically for that Where they load the ACM into to execute that, right? Yeah But it gets verified if I so if I remember correctly all ACMs have like signature And the the key to verify these ACMs, which is which is quite fancy. It's actually in the CPU, right? So there are ACMs for dedicated CPUs or they are Yeah, every CPU basically has dedicated ACMs that you can run Yeah, and every CPU also just for info has firmware itself. So CPU is not firmware less It's not a piece of hardware. It has also multiple firmware components in there. They're quite small But they are there. No, so it's really important and another interesting thing is some of the Intel ACMs are encrypted so I guess for bios card They use an encrypted ACM to protect against reverse engineering. I guess so it's some additional protection mechanism I don't know where the key comes from to decrypt it But I think it comes also from the CPU not sure what they use there, but you know what encryption they use No, okay, that would be interesting. Yeah, we can probably look into that I mean, we have at least NDA level access, but it's it's it's kind of let's say It's also hard to dig through those documents. And one thing to note also is you have different versions of ACMs, right? You can have like a debug ACM Yeah, which can only run on On pre-production hardware, right? Yes at the OEM basically when they when they spin the first boards You've got non-production worthy ACMs, which is kind of something in between I don't know. Yeah, and you got the production worthy ACMs and all of the ACMs you only get under NDA, right? Yeah, that's correct. No So what have we next we have the firmware security header So as there's one header called fit firmware interface table, which is basically a CPU Carseable data structure. So you need to know The ACMs we talked about are located inside the firmware image and you somehow need to load it, right? And the CPU doesn't know where where it is So it maps in the beginning of the of the platform bring up the CPU memory maps the entire let's say up to 60 megabytes of SPI flash or the bios flash into at the reset factor of the CPU and So CPU and somehow needs to pass this fit to figure out where the ACM is and so This is what fit does It's I guess it's all they are already some documentation about it or especially in the cobalt project You probably can check it out. There's some nice graphically included in the slides. You can see it's more like cobalt base but you can see what kind of Let's say offsets the fit is referring to and it's a binary data format So that's no common data format just binary data format And it's easy to to pass for the CPU because the CPU doesn't have so much Firmware, right? So it has not enough space probably to include an JSON password. Yeah, right But yeah in in the fit as you can find location of microcode updates, you can find ACMs and also the other PMware headers that you need as we already mentioned like KM and BPM and these kind of things, right? Which we'll explain probably in the next slides But all these kind of information where to find those stuff is actually located in that fit table. Yeah Yeah, another Firmware security header is the key manifest So as the name already tells you it's it's for key management. So it's the high-level key hierarchy Manifest it's also passed by the ACM. So not by the CPU itself. If the ACM is loaded It it will pass a key manifest It contains a lot of hashes from public keys So there are different kinds of security technologies as we already mentioned for the conversion security strategy which can be validated through the key manifest and Yeah, the signature of the key manifest itself is verified through the Hash of the public key which is attached to the to the key manifest itself So not not the hash but the public key is attached the hash is burned into a few this into the south bridge So into into let me if you're mad. So basically what they're doing is They move with that with the technology basically what they do is they move the rule of trust into the south bridge, right? Yes, because they're fusing The the hash of the public key in the me, right? And that is like a one-time thing that you can actually do right? So it's one it's one way direction I can fuse and cannot unfuse it again if it's in production and then the ACM which is Signed by Intel and verified to CPU actually checks if that KM is the valid KM If it has been like signed by a valid by a valid key, right? Yeah, and that's that's how they build up that route of trust, right? And before they use like different route of trust technologies like for I don't know legacy TXC That's called where they have to add like TPM and these kind of things But now what that is moved into the south bridge and combined with the CPU, right? So their own city can basically and started from there. Yeah, so it's also probably the most secure idea. It's probably not that Let's say independent from it anymore. It's less open. I would say yeah, let's open But it has a probably the benefits that the Intel me has some kind of hardware protection mechanisms Which are probably better than the TPM. I am it's probably TEPA Evident instead of resistant, but I don't know I mean either I mean TPMs already like a hard catch, right? Yeah, if that's better, I don't know, but I do get the idea, right? So I moved everything into Intel IP basically and have everything under their control Which probably makes it so they also use binary data from the binary data format So it's again, not Jason now XML or something like that Yeah, I mean XML can be also quite confusing anyway So, yeah, and then we need to see you so the CPU has some cash already before the memories available right and the AC RAM Chris spoke about is basically on placed inside this CPU cash and Yeah, during early launch the CPU passes the fit table figures out where the AC MS loads it into the cache Into the AC RAM location, which is shielded or protected And then it does the verification over it and after signature verification Is done then it gets executed and this is how basically How that works and also CPU is quite important because a lot of registers in it like MSR registers Which are programmed by through the ACM. So the ACM is basically the core root of trust code Which is then doing all other or further steps now. Yeah, I think you can kind of Interpret the ACMS like you're probably your trusted computing base right because that's like the first real code Let's say that runs there. Of course, everything is closed source NDA. I don't know if you want to have that as a piece But still it's like the first real real code that that runs and does the verification, right? Yeah That's true. Yeah, I sense Yeah, it's Intel management engine. We already talked about so it's basically the Southbridge firmware Nowadays, I guess it has eight megabytes probably more It depends right so there are different types of so yeah, I mean Management engine is not management, right? Yeah, there are multiple let's say version for server client platforms IOT But let's say in general they all have benefits which basically meets additional features that like for server space They have monitoring features for for the customer for the client Which means desktop and mobile platforms They have some kind of remote management and whatever and it also is able to run Java little so Java little machine So you can load your own Java applets into the Intel management engine. It'll make the probably Is this innovation engine that they talk about? No, no, no, this is a digital so you have also Intel innovation engine But it's a separate part of it. So it's it's a different story But let's just concentrate on the Intel management It's an engine in the engine, right? Yeah, which is okay. Yeah, okay Okay, so Yeah, it's and the inter management engine is highly involved in all those platform security technologies from Intel I must be said it's it's really part of the the firmware Image from the ME is a separate from from the BIOS and it has its own data petition inside It's not only code. It's also integrated data petition You can figure out there. There's a lot of research and reverse engineering arm regarding Intel ME You can probably get some more information about it and it also the most important thing it has some kind of confuration inside Inside the data. So let's say data petition and it has the fuses which are important for security Yeah, yeah, that makes sense. So for those who are wondering I mean, I think there are a lot of talks about Intel ME, right? What the management engine does and what not in these kind of things Out of an IVV perspective perspective basically What you what you put in there is like all your hardware configuration They are not what PCIe slots you have what status lots and these kind of things what should be done if I don't know if the machine boots up and you have food got enabled and then the keys are not correct in these kind of things, right? So that's actually a lot to configure there and also that tooling is NDA and closed source and I would probably say there Over 200 options or so for a normal platform that you have to configure in order to get it right. So The the the space for errors is quite big there I would say right so even we are dealing with that on the baby days is and It's still very complicated. Yeah, that's completely true. Yeah Yeah, so platform loop flow, so we will give you a rough overview of how it works We can go into deep in detail in 40 minutes. That's that's probably impossible So even with I guess six hours it you have edge cases and things you can't Cover so it's a topic for multiple days if you want to get more detailed information Please check out Ronald Hudson's blog about but that's a good one. Yeah, then you get definitely more details from it In general as we explained it before The pch maps firmware at reset vector, which is basically on the bios firmware CPU parses them to fit Table then it loads the ACM into a serum It verifies and executes it and the ACM does some platform checks, right? so it's basically security check checks if it's production worthy or whatever and Figures out what's going on. You can see that in that small Schematics there. It's it's not that complex. We already talked about I mean what how you can imagine that is basically when the PCA maps firmware at the reset vector means like the reset vector on Intellect 66 system is just below 4 gigabyte, right? I like always and what the pch does it maps your 16 MB or 30 to be like in the last 16 MB or 32 MB of that For gear but I guess it's only possible with 16. So there's some other element It's extended. Yeah, so 16 was I think To coffee leg or so. Yeah, but they extended that nowadays on the new generation platforms But still okay, let's assume it's the last 16 MB of your just below the 40 for gigabytes That's also why in the image that we put in there basically shows you have to imagine on the left-hand side There is like zero gigabyte right and on the on the right-hand side where the fit Is located the fit point is located. That's four gigabytes And that's also the reason why the BIOS has its own SPI driver Because if it's more than 16 megabytes memory maps, then you need to have your SPI driver You need to go through the SPI control actually to fetch more code. Yeah Yeah The next part is that the ACM passes to fit which is basically And they are to figure out where the cam is located so the cam and ACM are part of the BIOS firmware so and This is what it does and then the ACM also reads the the public key hash from the Intel MEE if users verifies the KM passes its data Uses the public key inside the cam to verify and load for the technologies. Yeah, right? So I mean this is quite easy It's just like a handover the key manifest is more to make it flexible for multiple security technologies But that's how it goes and after that Technologies like Intel comes into play. Yeah, so we will talk about that later I mean, that's exactly that that structure that we just talked about right look the ACM first verify that part and then Check against the KM if that is the better part, you know And from there you can actually take it and bury the bury that that Trust into the CPU and the PCA tried and then you have your your setup ready to go And you have you know that that the KM that you actually loaded is valid, right? The ACM is valid and from there you can take it That's basically the same for it for all the security technology that they have Yeah, this is completely true. Yeah Okay, um, yeah So after that that brief overview on how conversion beauty Works basically We can we can go a little bit more into into boot guard and trust execution technology, right? So that's the tool of these inter technology that they merge together And we can we can skip a little bit through these To to get a better feeling on that because that is that is the main topic of the talk here basically um so, yeah, I Think two generations ago or three generations ago Interdecided basically to merge and and and yes start that strategy that you just talked about right and to merge The first part was to watch boot guard and txt into one technology because they are all of those of these technology are based on ACMs and that you don't have like three ACMs to to have post technology working You don't need to anymore, right? And they named it converge boot guard and txt so in a short before it's cvng pretty catch a catchy name if you if you take it and as I said it contains two technologies that has boot guard in there and it has trust execution technology in there In the boot guard. So both of these technology have like a different purpose, right? So and That also makes sense boot guard is It actually protects the first part of the code that you load right at the reset vector and txt on the other hand This is just an execution environment, right? You have runtime measurements. So you have the DRTM instead of an SRTM You probably want to explain what SRTM and DRTM is. Yeah, static route of trust for measurement is basically a thing where you have the bios code starting measuring stuff into tpm So it's a chain of trust down to the operating system You measure our code before you load it and execute it the next code is measuring before loads the next code And so on and so it's static if you're having something like DRTM, which is more like runtime measurements You can just invoke during runtime secure code base or let's say secure trust anchor which then does active measurements Of something. Yeah, and and SRTM is always yeah as the name already says statically right from Basically from when when the CPU starts you start your your chain of trust right all down to the operating system DRTM can be involved at any time. It's dynamic. Yeah, that's basically the D in the name Yeah, it also has some I will I will menu protection Mechanisms and it's starting some something called measured launch environment. I don't want to get too deep into that But it's used in Windows 10 in device guard for example So Windows 10 makes extensive uses of trusted execution environments and until TXT is one of those Yeah, and it's verified through the covert security technology nowadays so TNT Exactly follows the the scheme that you that you just explained basically And you have a couple of important things that you actually have there of course you have the ME again, right or the Server part of the management engine You have a couple of famous security headers. Of course, you got fit table as always you got a KAM as always But this time you also BPM. I think we will go into that later on We have an initial boot block And of course, you need some bias Vice you buy a few more code. I probably don't need it But it would be better for some kind of technologies. So yeah, yeah, that's if you want to put something in general It would be nice. Yeah, so for sure All right. Yeah, the intimate management engine it basically so besides the He fuses the fuses right so the the hash of the public key. It also come contains some configuration data, right? You can actually configure CBNT or the bootguard part of CBNT to run in different modes. So either can be completely disabled We have it in verified or measure boot or basically in both right? Yeah What you can also do is Enable txt or disable txt. So even though they merge these technologies together together, you can still Enable only one part right? So if you only need the bootguard feature From CBNT just enable boot guard and off you go, right? If you only need txt feature of that of CBNT only enable txt and off you go And that also that all the things are is actually put into the inter management engine, right? Yeah, and it also contains What to do if an error occurs when you actually start a bootguard, right? So Imagine if you start your system and basically You don't start the code that you expect to start right so the measurements are wrong What are you doing, right? Yeah, do you do nothing? So basically you say, okay, I don't care I got a remote as station later on Why then having wood got it all but okay, but for D by me proposes or for example, that's quite nice You can shut down immediately, which is you don't get your computer on anymore Or you can say okay, you got x seconds or minutes to actually solve the problem So that you get some good guy some keep up with a funny part is that this and Enforcement policy is one of the dangerous things they ever introduced because there's the do nothing option And some balance already configured to do nothing options. So the security is basically not there I mean for remote is station a better feature would be enough So you can then it's it's basically also the question if you want to shut down the platform Normally a measure boot is not enforcing which is quite good. And so yeah, yeah Yeah, that makes sense. Yeah, and that's also one one of our key things here These configuration are quite opaque, right? So no one knows what you really configured there So they don't put like stickers on top. Yes, we have to nothing and they would don't worry, right? Let's think Yeah, what's the initial boot block? Yeah, as I already said, it's the first code that is loaded as part of your firmware code It can can consist of multiple sections. So that doesn't mean it it does not have one have to be one sequential part of Binary code in your firmware, right? So it can be at different places and your firmware actually loads different parts of that code, right? so that means These initial boot block basically is defined in the BPM, right? And there you can actually find multiple IVBs like initial book blocks and not only one obviously But which makes sense and the idea of these IVBs is that before the firmware start These parts already already get measured into the TPR, right? Yeah, and they are basically verified like in the secure boot or very file boot environment, right? So so they use those sections defined in the BPM. They also have multiple hashes with different crypto algorithms Which is the final hash and then the K-Kool-Aid Is all those IVBs together and get a final hash and if that matches the BPM you can say you're good to go Yeah, that's how it works and additionally to that you can also the ACM also measures it into the TPM if you activated measure Boot-based in the internal management engine for later use I know remote is stationary if you want to just have your your measurement lock, right? Yeah, these things make sense. Yeah, and basically the core part here is that boot policy manifest It enforces the boot policy, which is partially the ACM You can configure multiple protection and platform features in that I think we also in the demo later on we can go a little bit through that like what kind of options do you have there? As we already said it defines IVBs and also the expected hash values for these IVBs And a signature protected right and that that hash of that public key Where the private key actually signed that BPM that hash is in the KAM, right? And that is how we extend the chain because KAM is already verified by ACM So, you know, that is vetted and in T. You're basically and in that KAM, there are hashes of the public key of the BPM and with that Public key you can actually verify the signature of the BPM, right? So that is how you how you extend your chain there also through the BPM And again, it's binary data format. No weeks in my chains I think I think that's for nearly all the structures which are in firmware. Yeah Yeah, and the last last part is the by-sync. I firmware code We are which you need you can find a great source how we did it implemented because it's open So we implemented it as part of the corporate project for customers No, and you can find it is basically to report CBNT errors and statuses But it's also there for the initializing the dynamic route of trust for measurements because it's an additional ACM for the operating systems hypervisor, so You need to load an additional ACM which is signed by Intel at runtime inside the operating system or before the operating system inside the bootloader and So where you can build out can build up your your dynamic route of trust for measurement, right? Yeah, you have exactly two ACMs for CBNT, right? So the first one's a startup ACM which Gets loaded before all the other firmware codes gets loaded right and it verifies exactly what you said, right? Against the ME fuses it very afraid where fights the KM and these kind of things and you have the acid and ACM Which is there for the DRTM later on which you are now loading in team for example. Yeah, that's correct All right So we sketched a little bit the inter CVT boot flow here As Yeah Basically, it's the same as a little bit or it's it's similar to what what we do with the KM So the ACM first verifies or first loads and then verifies the BPM So it does check if the if the hash of the of the public key Of the BPM is actually in the KM and if it's the same If that is correct and verified it Parses the BPM then it looks for these IBB sections Which are defined in that BPM because it knows the BPM is valid and can be trusted It looks for these IBB sections and calculate Calculates of hash value of these sections in firmware, right? So the final hash it's just one hash. So it's basically has to get yeah, right the final hash of these all these sections And then it compares what it's calculated on it on its own on the actual firmware with what should it be? Which is defined in the BPM, right? And if these hash values are equal it knows all right Everything's fine My my IBB is still what I expected to be basically and then it hands off to reset vector and off you go Yeah, if it's not if it's not valid or can't be verified it with directly as we say shut down or shut down After a specific amount of time. Yeah, and that's it or do nothing if you put in do nothing Okay, so we come to the more interesting topic. I would say we explained law of information regarding inter security technologies So we have something called converge security suite. That's Something we developed Sometime ago, so two years ago. We started with it basically So we until then we were running graphical tools into tools. Yeah, basically Underline it's not only until it's also MD and other companies. So and it was really a horrible user experience The problem is also how do you automate that if that's a graphical user interface How do you do automation with some kind of automatic signing processes or whatever? It's just it's just 2022 So and there was also no testing available for the operating system So you could test Insights a ufi shell with your family, but you always had to restart you have to execute it inside the shell and somehow load it I mean, it's possible, but it's really horrible Interfacing it's complicated and it's it's not really why don't you do that in the operating system works still fine So you probably you have to to set some specific options for the kernel or create an ISO image Which can do that, but why do we need a ufi shop for that? Yeah, and it's it also means it only supports you if I right if you have anything else like like So female like cobalt of these kind of things you out of the game because yeah, all you have to know tianocore then all those tools Even though the graphical tools for for creating those manifest like BPM on KM. We're completely ufi centric So this is like not really cool. So Short story we started on our own Yeah, so basically the converged security suite you can find it on github It's open source tooling for platform security features at the moment. We support internet AMD Platform security features AMD is currently let's say work in progress, but they're already started with it Yeah, it's fear Magnostic. We don't care about fear mess So just give us an image and so all those technology headers and whatever is completely Agnostic from from from the firmware which is used even if it's cobalt df is limbo load or whatever So it's not a problem for our suite It can be used for provisioning which is more important for the odm's or ibv's like us Which means female images provisioning creating those manifest and so on a testing for runtime testing Which is really nice if you can for example do tx intertix t runtime verification So if the tx implementations correct and but also binary testing research and security audits are also really important Yeah, so this is where it's basically used. I mean we started from the testing part, right? So that's that's where we came from, right? Yeah, so we had to check if all the txc features Actually there and available and from there it just evolved because then we notice okay We actually it's not how it should be and now we want to provision our own platform And there's also no tooling right and the fun part now is We can do everything with ufi because like we include ufi However, it doesn't work the other way around right like the open source firmware image images do not work in Windows 2 It works like that. Thanks. Yeah, that's correct Funny part is we have vsd 3 license. So that's quite good We are hosted on github written in pure golem Which is really great because we don't have C dependency or whatever you can in theory We can run the tool we wrote or some tools you can run on windows as well So we didn't do that until now But probably someone want to go for it because for us linux was more important We use the file system parser called fiano, which is really nice because it should implement all firmware file systems Which are basically not really well known. So check it out, please. It's really nice. I added some reference later on We also so at the moment we have support for cbt provisioning for txt provisioning for txt testing at runtime And we have a pcr0 diagnostics tool So the most people don't know but the tpm pcr0 is basically calculated from specific type of Of code and money system whatever From those binary images. So it's really and from runtime information. So it's really complicated to do that That's why we have those tools and that's plenty and yeah, that's right I mean, that's especially nice if you if you want to check pcr0, right? I mean, that's like the most important one basically If you want to see okay, what does the acm measures here and if you want to do some precalculation all these kind of things pcr0 is actually the the prejudices that you're looking for and Yeah, it's it's important that you know what's going on there, basically I think we also have boot guard provisioning on the way at least Okay That is that is I used it already. Yeah, say like that It's not production. It's not production in the end and not all NDAs are cleared, but it's on the way. That's good. Yeah Yeah, aside from that, how did we make it public even with NDA? So first of all, there are tons of official public code Documentation from Intel so you can find it. It's hard to find but you can find it and they already Made a lot of code public So we only had some parts which we're hard to figure out which we use trying error methods to Get some information out of this by key generation signal generation hash calculation and female platform conversions basically boot code built and brick and Do that for a long time. So it's really it's exhausting. It takes a lot of resources. It's painful But we did it so and what we all did for for structures with which can't be public We will be renames them all to reserve Standard Ray and Intel data sheets, but it's under one person. I would say also of our code base, which is fine Yeah, I guess it only has problem this into PFR, which is not really public yet Yeah, so but yeah, this is kind of cool. Yeah, I think we we did a pretty good job there on finding all these Public coding documentation right on on different I think we used eight or ten different repos and there was some some structures here and some structures there and actually Sometimes I know field A and B were Publicly available, but on the other repo food if you'd am B were reserved, right? So they're not publicly known, but you got food see it. So we mixed it all together and basically Got like the biggest common nanner of all these things out there And yeah, so that way we could actually make it public because it was already public But we had to gather the information and that that Was actually quite quite a lot of work That's that's true But the good thing is interest going into more open direction for for for fear of security or hardware security technologies I think this will change Later and it would be good if we can show them that we have a cool convert security suite Which is public and can be everywhere integrated Yeah, and also to mention, I mean we work with Intel engineers together on these kinds of things for sure. Um, so that is That is also we have a good working relationship with them and yeah, they helped us out here and there. So that's that's cool stuff Yeah, so what's the roadmap for the future? So we want to have basically more AMD tooling So AMD has similar stuff Which needs to be passed for example AMD PSP provisioning AMD five system support all that strange things We have Intel PFR. It just not yet is there yet We want we want also to implement a CBNT test suite. I think this is not done yet, but we'll probably Happen later or sooner depending on how much pressure we get from the customer side as well But we also have already some other companies working on on our culture. So it's not like we are alone Yeah, um, yeah, we want to do Linux distro packages integration probably someone wants to do windows as well I'm open for it And we will move all five system related packages to fiano So please check it out. Which is a nice goal and library for fmv passing I think we already moved a lot of stuff over right, but it's not complete yet. Yeah, not completed So and next we have a short as no demonstration. I guess we're running out of time, but Um, however, we still like to show you And and how you can use it right So I already cloned the repo In into our into our go source folder What do you have fears like our normal structure of the directory and in the command folder? You can find a couple of tools, right? So we got the CBNT provisioning tool We got the PCI-02 we got the txt provisioning tool in the txt test suite All right, we could probably start with the CBNT provisioning tool You just type go build and it bits it And you got the CBNT provisioning tool here, which you can run on the command line It gives you a couple of options that you can use Yeah, I have let me check it out I have I Have some demo folder made up Which I have to jump over They got the CBNT provisioning tooling that I just Did I just build and we got two images? We got a ufi image and we got the corporate image, right? So it doesn't matter which one to show. So we just go for let's say the ufi image And what it gives you so let's let's move from the top here You know it's so as you see it's a lot of information So first of all it prints you like the whole fit table that you have Which is which is that one here? It gives you like what type of entry do you have we got the header entry first of all We got I know microwave updates. We got a couple of skip entry entries We got the startup ACM, right? We got a couple of other ACMs here And we got a couple of legacy policy records even though it's it's it's for a CBNT platform OEMs and tend to include everything they have basically Just to be feature complete. However The we always We always do these sections here With the with the with the four dashes and there comes a boot policy manifest Within the boot policy manifest you have a couple of structures, right? First of all, you have the header we have like signature and revision and these kind of things in there and then we have the most Interest into interesting part is actually segment elements part. So that is where your IBB's Defined later on right here is also the the ash value that you can expect later on that gets measured into Or should have get measured into the TPR And you can also find a defined a couple of IBB segments as shown here Which which the ACM then should measure right and these are exactly the parts that we talked about Which the ACM looks into the BPM and gets these IBB segments and measures all these parts from the firmware into into the TPM for example or at least measure hash them all together and compares the calculated hash values of these IBB segments with the with the hash values here on top and If they're equal everything's fine and they move on, right? Yeah, you also have tons of other options I guess that would be too much for now because we are already running out of time So and you could also show your provision it But it's all also documented in the github repository so you can figure out everything yourself The txt is free tooling you can also execute on your own laptop and figure out if your txt are compliant It's very strict. So it's probably showing errors even if you have a ufi which supports into txt, which is really nice No, yeah, but aside from that. That's how it works. You can see the KMS BPM and to fit table So and also it's signature and so on. Yeah, so I think this is also quite helpful I think so too. So that is the KM part here also, you have like general information here on top and then that is exactly the The hash of the of the public key part of the signing key of the BPM, right? And that is exactly in here So that is how how you extend the chain and it also If you print something like I think it's game show Yeah, this is a data section of the KM right, okay And it's a ufi image right so it's a little bit yeah, so vendor section which additional I don't know data or whatever which yeah, so you can also only part only show like the KM part and BPM part You can also extract it if you want to You can all do stitch like new BPMs in there you can sign and BPM you can create Or generate and and BPM five based on the Jason configuration and these kind of things right so you can use that Who we have the tool for it just checking out what's in the firmware But also extracting everything from the firmware provisioning everything changing stitching all these kind of things that you probably need All right, and the other thing that we can show is the probably the test suite right the txt one We don't have a txt system So So it will give us a lot of errors. However, just that you that you see How you can how you can do it I Got to execute tests right yeah, and there you get we have like 75 tests implemented right now And a lot of these fail on this machine obviously because we don't have we don't have a TPM for example Yeah, but that is on an all the system you would you could check okay All these rules are actually in place and are we compliant to the to the txt spec, right? Okay That's so can you switch as a project again that would be helpful. Okay. Thank you So I've only last two slides. I need to speed up Call to action. Yes Jonas. It's open source here mess like a slack dot osf W dot death with the convert security channel Please also get in contact with us to get up. So if you've code ideas or bugs just Publish let's say make a pull request or whatever be open for everything and spread the word Especially for all the elements like quanta or this trend and also for the female security pentas that which also might Be interested in that. Yeah, that might be it. Yeah Does it work? No, not really but I think it broke. Okay, so Looks like the keyboard went out That's perfect. It's not even live right? Yeah I just attached to public resources at the end just figures it out and yeah Thanks for listening and joining us for the talk. Yeah. Thanks everyone Yeah, have fun with the remaining talks on the open source summit and Yeah Getting contact with us if you want to know more about the conversion to sweet or any Intersecurity related things problems whatsoever. I think we can help you out You