 So, today, we will be focusing on a few things about CIP, then the main focus of this presentation is secure boot and software update activities in CIP. And there have been some updates related to IEC 6243 certification activities. And we are doing multiple activities in that direction. And then we will see some other details related to IEC, and then we'll have a Q&A session. So briefly about CIP, so the main motivation behind CIP is to basically collaborate with other open source projects and working with other upstream projects to help each other and reuse the effort which is being contributed in different open source communities. So as part of this, CIP contributes in multiple other open source projects, such as reputational builds, attribute card, and many others. And that way, we continuously contribute and collaborate with multiple open source communities. So basically, CIP was started to solve some of the key issues in industries which are common and most of the players face and they try to solve similar kind of issues. So to solve especially like having industrial-grade softwares with long-term support and industrial-grade security and reuse the open source components. So these are the key issues where CIP was started by multiple industry players. So we'll see some more details about that. In CIP, basically we have an open source base layer which comprises of CIP core packages and CIP kernel. So as part of CIP main development, we focus on continuously for long-term maintaining CIP kernel and CIP core packages. So currently, the latest kernel CIP has supported for super long-term support is 5.10 kernel. And as part of IEC certification activities, we are focusing to strengthen this OSB layer and here as part of IEC certification activities, CIP kernel needs some additional things to meet IEC requirements and same as the gates with the CIP core packages. So we'll see further details about that. So as a CIP platform, basically we build and maintain pre-production base layers OSBL and then members from CIP and other community members can reuse that and they can make course customizations and they can contribute back. CIP also maintains its own version of real-time kernel and it's continuously upgraded to latest patches which is maintained by dedicated CIP kernel maintainers and it's supported by key Linux kernel developers. So regularly, CIP kernel maintainers keep collaborating with the kernel developers. And there are multiple reference hardware supported by CIP and there is a certain process to select a reference hardware in CIP and then on those reference hardware all the test which includes CIP kernel test as well as CIP core test, they are continuously executed and some of the collaboration is also started with kernel CIP where test gels are published and one of the important focus area for CIP is to have a super long-term support for up to 10 years. Then in CIP is supported by multiple work groups. So in CIP mainly we have CIP kernel work group or testing work group, CIP core work group and CIP security work group as well as CIP software update work group. So we are basically from security work group and our current focus is to get CIP certified for IEC 62040, 4-1 and 4-2. The main work in CIP core basically is to maintain a reference image and the main topic of today's presentation which is support and software update support is primarily comes from CIP core work group as well as CIP kernel work group. So from CIP security work group side we are basically collaborating with all the work group members for meeting IEC requirements as well as adding additional features to include additional packages as well as additional kernel configurations to meet IEC requirements. So different work groups have different meetings and they keep regularly communicating. Some work groups have bi-weekly meetings, some have weekly meetings and that way there is strong collaboration among all the work groups to share things and to discuss the roadmap and all those things. So in this presentation we are not talking about much details of other work groups because we want to more focus on secure boot and software update support. So for CIP security work group one of the key goals is related to IEC certification and basically identifying the required additional packages to add in CIP core layer as well as identifying additional kernel conflicts to add and collaborating with other work group members and certification body. Apart from that we also investigate other security standards to find out what additional security things can be added in CIP like NASD standards and hardening practices. So for that also we have recently some work and we are also planning to start some collaboration with OpenSSF which has got a lot of good stuff in security which will be quite useful for CIP to also apply in CIP layers. So next is the support of secure boot and software update. So basically this requirement comes from IEC and it's not just IEC requirements but it's one of the key requirements for any system to have security in place. So from IEC perspective there are key requirements such as maintaining the integrity of the boot process to ensure that integrity of the firmware, software and configuration data is maintained and it is verified when the system is booted and apart from that authenticity of the boot process. The product supplier's root suppress is maintained and it is verified at every boot. So these are the key requirements of IEC to address these requirements in CIP since quite some time CIP kernel maintainers as well as CIP core members are working to make the support available and for AMD64 and for ARM64 we have already supported this and still there is some work going on. So more details will be there in coming slides about that. And similarly from IEC perspective there is also a requirement of having secure software updates where the software updates should be supported through signed images as well as encrypted images. So that support have been already enabled and it's in place in ESA's CIP core project. So the details can be found in GitLab projects. There is a reference for that. So next Venkat will be explaining about more details and support of secure boot and software updates. Thank you. Thank you Dinesh. It's me again Venkat. So I will be talking about on secure boot and software update from the perspective of security group. So how it is implemented in CIP platform. So here I'm not a hacker or I'm not an ethical or non-ethical hacker or I'm not a secure expert. So I just want to talk about my learning about secure, how security we can implement in some of the platforms. So next slide. So what is secure boot? So maybe I've taken some of the definitions from the Google. So it's a standard developed for PC industry to make sure the device boot using a trusted software. Yeah. And also it says it should detect any tampering in the system in the boot stages. So it has to be eradicated. So there's another definition. Yeah. So let's say secure boot. Yeah. It's a verification mechanism that ensures the code launched by the computer is from where it is trusted. Yeah. So this is secure boot. And why this secure boot is important now? Because nowadays the hackers are sending some fake security patches and sitting in the system and in the boot stages and they're getting access to the systems and doing vulnerability attacks. Sorry. So basically we need to resist these attacks or infections from these malicious softwares and get the customers trust. Of course. And it's one of the requirements in high standard. So that's why we're talking about today. Going to next. Yeah. Yeah. This is a secure boot stages and embedded platforms. So in CAP, it uses UV based secure boot. So and every stage in this boot sequence should be validated. In CAP currently we verified on chemo target and on real hardware is working progress. We have to finalize the hardware first. And then it because it requires a secure storage and needs some dependencies. So it's still working progress. Yeah. In the coming slides, I'm going to explain about each stage of the boot sequence and I'll explain how it is verified. Yeah. In the first phase, we should have a secure boot keys. So it is defined by UV specification. How secure boot should process with various secure boot keys. So there are these are different keys used in for getting validated or the complete secure boot process is validated using these keys. So I go by one by one is the first one is a platform key, which is the main key, which is I think it will be fused in hardware or the platform owner as gives this key and he and it builds the trust between the platform owner and the hardware, the firmware. The next is a key exchange keys. So basically this is to validate the next DB and DBX databases or those those content actual certificates which is used for signing the So to update any of these databases, so a key exchange keys should be verified, either platform key or anything you can use. So there is many purposes to validate the DB and DBX. So DB and DBX contains the list of certificates that DB contains the wide list of certificates or the accepted certificates, which needs to be verified in the database which are signed. And DBX contains the blacklist certificates or the malicious certificates which will the firmware or the e-formular will try to stop the primary job sign with all these certificates for the DBX. So this is about the certificates and the general code process. So in CEP, in CEP it uses two mechanisms. We did that practice using the generated keys. The generated keys, that means all the keys is a sign of self-generated and for the demonstration purpose we can use these keys. And all the process we can validate. So there is a script in the CEP code. These are CEP code source code which will generate all of these keys, PK, DAT and DB, using the necessary commands and EFI to prepare these certificates for the CEP code process. And it needs to be generated, OBMF to ask for it. Maybe I will talk about OBMF in the next slide. But I will give a small introduction. This is an open virtual permission firmware. So it is for QMU because in CEP we initially verified and set your code on QMU. So we need to generate a vast file that contains these all keys. So with the help of kitool.dfi program, we need to embed all these keys. They are visible or not. I am not sure. The steps to embed the keys with the help of kitool.dfi. So once, if it involves the steps, those keys will be embedded into the OBMF vast file. And that will be eventually used in secure boot process. So another method is a snake oil keys. In this method, we know to generate the pre-generated keys. So you can install OBMF package which ships these files in user share folder. You can see the vast file which has embedded with the snake oil keys. Which is the OBMF package. You can see the vast file which has embedded with the snake oil keys. Which is having already pk and kek all such wickets. So next is about the firmware. So we have talked about the secure boot keys. And now we are ready with the keys. Now the firmware. So we need to choose a UF based firmware because we are implementing UF based secure boot. So it needs UF based implementation. That is the reason we have chosen OBMF which is based on UF. It is reference implementation from EDK2. So yeah, this is the firmware. You can also get it in OBMF package. So when you install, you will find it under this folder, user share, OBMF, and OBMF code file. So this is we used for X86 or MD64 platform. And whereas in ARM architecture, we have some issues with OBJ copy and this AVMF, A-A-V-M-F, sorry. So that's why we have alternately used UBOOT with UFI as a firmware for ARM architectures. It's for QMU, of course. So we need to enable these two configs in UBOOT to make UBOOT enable with UFI and secure boot. So in UBOOT, we are... The CAP is embedding the secure boot keys inside the UBOOT statically. So that is why the config if a variable is pressed is there. And so once... Yeah, firmware is there, is ready. And now it's a bootloader which needs to be verified by firmware, of course. So we... Or CAP uses EFI boot guard. It is not mandatory. You can use any bootloader. But EFI boot guard, it is used in CAP for other purpose as well. In software update, it needs some functionality, watch-doculated functionality. So it has chosen EFI boot guard. Or you can choose UBOOT as well. So any bootloader should be signed with secure boot keys that are generated in the previous slides. So in the previous slides, you will maybe getting the keys. So you can use the SB sign tool to sign the bootloader. You need the SB sign tool package to get this tool. That's the bootloader. Next is the unified kernel image. So in the boot process, after bootloader, there are general usual ways to load the kernel and then you need trimFS. But here we have used unified kernel because for assigning multiple artifacts like kernel, any trimFS and command line is quite complex. So unified kernel helps you combine all these artifacts into a single image. And you can sign that image with OBG copy. Sorry, you can club them using your OBG copy or using a tool from EFI boot guard that is BG-gen unified kernel. So CEP is using these to, yeah, same reason that we need it for other purpose of software update. So you can use OBG copy as well to club or to create the unified kernel image. So that is a command for the BG-gen unified kernel image to generate unified kernel and then sign the unified kernel with the same command as explained in the previous slide. So this yeah, this creates unified kernel and signs this image. The finally is the root of s. So root of s uses DM variety device or it's a root of s it is used to so DM variety will create the the hash values of each node and creates a hash of it basically to verify the integrity of this and yeah, and also the signs. So so yeah, this about the root of s we use DM variety. Yeah, so the node is here. So the boot process is unified kernel comes first but during build stage you need to first generate the root of s with variety device and it generates the hash value and you need to include that hash value inside kernel command line parameters because kernel command lines are numbered in unified kernel. So first we need to generate root of s with variety and then include the hash value in the unified kernel and then sign the unified kernel. So that is the sequence in the build process. Oh, yeah. So that is all from the secure boot respective. So this secure boot is verified in all the boot stages. So so next it's about software updates. So yeah why we need this software updates because we need to upgrade the device with advanced features and get some performance and security fixes. Also it should provide authenticity and integrity as part of security feature we are talking about. So I have limited slides about software update. Sorry. So in CIP we use software update by SBabic open source tool. So it has many approaches how software update can be happened. We use a double copy approach because that is a straightforward. We need two partitions for this and to update so one will act as a backup and the main one is the actual root of expectation booted. Yeah. So this software update also supports via OTA or it uses also local storage. It supports signed software updates. It also supports signed software updates. Let's talk about in the next slide. So this is how the dual copy mechanism works in CIP. So there are two colors green and yellow two partitions those are dual copies so they both are same. So on live it chooses only one partition or one sequence so it boots the boot partition and mounts the root file system. When software update triggers it will update the other partitions and then it reboots and it updates actually after software update is successful in the root file system or in the live system so it uses bootloader variables to update the status of the software update. So it changes the boot partition when in the next boot so here is watchdog is used so when the boot partition so the boot partition be if there is any failure it has rollback mechanism it triggers watchdog triggers in a period of time it rollbacks to the previous partition if any failure so this is about the software update so this talk has already happened in the previous sessions you can see the difference you can find the more details in those previous sessions so this is a signed updates so here when we create software update image the diff image so we create the sub image and the description file is used for defining what is the image what is the type and what partitions and also it includes the root hash value of the sub image so that it helps to verify the integrity and then it combines and creates a or assigns this software description file to create authenticity authenticity check so it combines this and creates a SW file and this SW file is used for software update either OTA so it can use Huckbeat or local update so when software update is received in the device and it opens the SW file and checks the signature first and then once signature is passed then it reads the hash value from software description file and checks the integrity of the software update image then it proceeds for software update yeah this is how signed software updates proceeds I think I'll hand over to Dinesh thank you thanks Venkat so I will just have some updates from IEC perspective what we have been recently doing so we have basically completed the activity of investigating FODS 1 and FODS 2 and we also completed gap assessment with certification body and after that there were quite a few action items in CIP to complete so after like starting the work on those things we realized like there is lot of queries from CIP side and there were lot of back and forth in terms of queries with certification body so now like we have completed many action items but still there are quite a few and that is why now we are proceeding to engage with certification body for final certification and most likely we are going to make decision on this by end of this month or early next month and we will be entering into final certification phase for CIP so because of limited time I will skip few slides so as part of CIP security work group activities we have added multiple security packages in IEC layer as well as we have created several documents to meet IEC requirements and I will skip this slide then this is the detail about the IEC layer which has been added in ESSAP core project so this can be used to basically meet IEC 6244 as two requirements and for this separate test have been added and soon we are going to execute those tests regularly and the test cells will be available for anyone to check the details of those tests then this is the detail about the IEC documents repository and recently we have also added several other documents since my last session based on the gap assessment gaps so because of being open source there are still several gaps and we are trying to reuse most of the Debian practices and processes in CIP and there are quite a few challenges from open source because in open source we don't have very good defined processes in place so we have to work basically in terms of fixing those gaps so that we can strengthen the security of open source components so I will skip this slide as well so there are certain benefits once IEC becomes 6243 compliance it will be quite helpful to reduce the overall certification effort for CIP users as well as there will be a lot of documentation and additional packages available from CIP to reuse by CIP users so this is the long list of CIP supported reference hardware and it is of course growing and we are also planning to select some of the reference hardware from this list and this will be chosen for IEC certification so that discussion is currently in progress within CIP members so here in versus Japan we have CIP booth so I would request participants to please visit CIP booth and watch live demo which is basically running CIP kernel for some of the huge cases so CIP is supported by CIP community you can see the current CIP members and this list is of course growing and then we have some references and details so that's all thanks thank you so this is very interesting can you talk a little bit about the threat model that you have for software updates because from what I can see it looks like it doesn't seem to be concerned if the keys are stolen or the repository is compromised or other problems like that occur which I'm a little surprised to see because a lot of other modern updaters in this space address those issues thanks so the question is to how threat modeling is done in CIP and how the issues related to keeping the keys secure is being addressed so part of that modeling in CIP basically we considered how the data flow happens between CIP developer systems as well as upstream repositories now coming to the question of how are we making sure the security of keys because CIP being a reference platform so far we have not cared much about storing keys because we are just verifying those reference images and discarding keys now as we are entering into IC certification phase we are now working to identify reference hardware which is going to have a secure storage and then we care about those keys and make them secure and then accordingly our threat model also will be updated to include those scenarios so the detailed threat model is available in our CIP documentation you can have a look on that okay so I think what I understand from your answer is that it is not handled now but you want to handle it in the future yes okay all right I know people from the security side who would be very interested in collaborating with you to help to add that sure that will be quite interesting thanks any other questions thank you