 Hi everyone, my name is Abzal Hassan from Foundry Software Team of Samsung Semiconductor India Research. Me and my colleague Priyadikshit present today on this topic, enhancing system security by integrating Zafir Bookloader and MCUBoot. So in today's agenda, we present the importance of system security in Zafir Bookloader, system architecture of Zafir, integration process of Zafir Bookloader and MCUBoot, secure boot process of proposed bootloader, on-ware update process of proposed bootloader, rollback protection and bootloader recovery, threat model, limitations and challenges along with the future development. In today's digital landscape, system security is of paramount importance. To bolster the protection of embedded systems, the integration of Zafir Bookloader and MCUBoot emerges as a promising solution. Zafir Bookloader and open source scalable and secure bootloader provide a robust foundation for system bootloader. It incorporates advanced features such as secure boot, digital signatures, verification and measured boot ensuring the integrity and authenticity of critical components during the startup process. By integrating Zafir Bookloader with MCUBoot, a highly flexible and customizable firmware update framework, system security reaches new heights. MCUBoot offers secure firmware update utilizing cryptographic mechanisms and authentication protocol to safeguard against unauthorized modification. This integration empowers embedded system with a comprehensive security framework. Zafir Bookloader establishes a trusted chain of attribution verifying the authenticity of each component through digital signatures. Furthermore, MCUBoot ensures secure firmware update mitigating the risk of vulnerability and enhancing resilience against evolving threat. Together the Zafir Bookloader and MCUBoot amalgamate the power of secure boot and robust firmware update, fortifying system security and protecting against malicious attacks. This integration is a significant strive towards safeguarding embedded systems in diverse domains such as IoT, industrial automation and automotive where security is of paramount concern. Enhancer systems security by embracing the integration of Zafir Bookloader and MCUBoot are ensuring a resilient foundation for secure and trusted operations. Next we will discuss about Zafir Actors system architecture. Now in this slide we will discuss about Zafir system architecture along with its security components. A real-time operating system Zafir stands out as a robust and versatile platform for embedded applications. Its system architecture not only enables real-time responsiveness but also prioritizes security to protect against emerging threats. At the core of Zafir's architecture is a modular microkernel design. The lightweight approach allows for efficient resource utilization enabling the real-time operating system to run on a wide range of devices from resource-consuming microcontrollers to more powerful processors. The modularity also promotes code visibility, flexibility and flight-facilitating customization to suit specific application requirements. The Zafir real-time operating system incorporates several security features to fortify system resilience. It embraces the principle of defense in depth by implementing security mechanisms at multiple levels. This includes secure boot, encrypted communication, access control and memory protection. Secure boot ensures the integrity and authenticity of system firmware and software components during the boot process. It employs digital signatures to verify the authenticity of these components regarding against tampering and unauthorized modification. To protect data and transit, the Zafir real-time operating system offers various communication protocols with built-in encryption capabilities such as transport layer security. This ensures the confidentiality and integrity of sensitive information exchange between devices or network. Access control mechanism improves permissions and restrictions limiting the actions and privileges of different software components and users. By employing rule-based access control and other access management strategies, the Zafir real-time operating system mitigates the risk of unauthorized access and potential bridges. Memory protection mechanisms such as memory segmentation and other isolation techniques prevent unauthorized access or corruption of critical data and code, improving the system security portion. The system architecture of Zafir R2S combines scalability, flexibility and a robust security frame. Its modular design promotes resource efficiency and customization, while security features like secure boot, encrypted communication access control and memory protection mitigate risk and safeguard against threats. Embracing the Zafir real-time operating system empowers embedded system with a reliable foundation ensuring both real-time performance and robust security in a rapidly evolving digital landscape. In this slide, we'll discuss about the importance of system security in embedded world. In today's interconnected world, embedded systems play a vital role in powering critical infrastructure such as industrial control systems, IoT devices and automotive systems. With this increasing reliance, ensuring robust system security becomes paramount. Embedded systems control essential operation, monitor sensitive data and manage critical functions. Without proper security measures, the system is susceptible to cyber threats including data bridges, unauthorized access and malicious attacks. The consequences can be devastating, leading to operational disruptions, financial losses and compromise of user safety. System security in embedded systems is crucial for several reasons. Firstly, it safeguards the confidentiality and integrity of sensitive data. Industries handling financial transactions, personal information or intellectual property must prevent and raise access and protect against data bridges to maintain trust and regularity compliance. Secondly, system security ensures the availability and reliability of embedded systems. Industries relying on real-time operations such as manufacturing or healthcare cannot afford system failures or disruption. By implementing robust security measures, these systems remain resilient against attacks and maintain uninterrupted functionality. Furthermore, embedded systems operate within interconnecting environments, making them potential entry points for broader network attacks. Standards system security helps prevent compromised embedded devices from being used as gateways to infiltrate larger networks, thus protecting the integrity of entire ecosystem. Additionally, ensuring system security in embedded devices enhances user trust and confidence and users expect these devices to be secure. Whether it is a smart home device, a medical implant or a vehicle, robust security measures inspire confidence and reduce concerns regarding privacy, safety and the potential misuse of personal information. System security in embedded systems is essential for regularity compliance. Various industries must adhere to strict standards and regulation concerning data protection and system security. Maintaining these requirements not only avoids legal consequences but also demonstrates a commitment to maintaining the highest standards of security and reliability. Security in embedded systems is of utmost importance to protect critical infrastructure, sensitive data and user trust. By implementing robust security measures such as eco-boot, encryption, access control and continuous monitoring, embedded systems can withstand evolving cyber threats, ensuring the integrity, availability and reliability of essential operations in today's interconnected world. In this slide we will discuss about concept of integrating the Fireboot Loader and MCO. Integrating the Fireboot Loader with MCO would presence a powerful concept enhance firmware update security. By combining the strengths of these two components the system gains a comprehensive solution for secure and reliable firmware updates. As a Fireboot Loader known for its scalability and security features, establishes a trusted boot process ensuring the integrity of critical components during startup. It incorporates secure boot mechanism, digital signature verification and major boot establishing a chain of trust and safeguarding against sampling and unauthorized modification. On the other hand, MCO boot provides a flexible and customizing framework for secure firmware updates. It utilizes cryptographic techniques, authentication protocols and secure communication channels to ensure that only authorized and verified firmware updates are applied. The integration of the Fireboot Loader and MCO boot combines the benefit of secure boot It allows for seamless secure and efficient updates of firmware on embedded devices mitigating the risk of vulnerability and ensuring system resonance against evolving threats. This concept embedded system can confidently embrace secure firmware updates protecting against unauthorized modification, maintaining system integrity and delivering enhanced functionality to use. Integrating the Fireboot Loader and MCO boot presents a compelling concept that enhances firmware updates security. It combines the trusted boot process of the Fireboot Loader with the secure update capabilities of MCO boot providing a powerful solution for maintaining the integrity and security of embedded systems to reliable and secure firmware updates. In the next sections, we will discuss about the Fireboot Loader and MCO boot individually. In this slide, we will discuss about some of the Fireboot Loader features. It is famous for its lightweight design. It has a secure booting feature. It has firmware update support and cryptographic verification. Flexible configuration, error handling and the capability compatibility with the Fireart players and its integration. In this slide, we will discuss about the Fireboot Loader boot flow. As we know, the Fireboot Loader is responsible for initializing the system and loading the main application into memory on the Firebase devices. So, we can discuss about the high-level overview of the Fireboot Loader boot flow. So, on the Power On reset, when the device is Power On or reset the processor begin executing code from a predefined memory address, typically the bootloader's entry point. Then we will move on to the bootloader initialization. The bootloader code initializes essential hardware components such as clocks, memory and peripherals required for the devices operation. Then bootloader configuration. The bootloader may have parameters such as boot till a boot source selection or communication interface. It reads this communication option either from a dedicated configuration area in non-volatile memory, for example, dash or through other things to determine the boot period. Then we have the boot source selection. The bootloader determines the source from which to load the main application. The source can vary based on the system design and configuration, but common options include external flash memory, internal flash memory or an external storage device like an SD card or a network interface. Then we move on to the loading of the application. The bootloader reads the main application image from the selected boot. It typically verifies the integrity and authenticity of the image using pictographic signature or checksums to ensure that the application has been tampered with or any overwritten thing is happening. Optional authentication is also possible if the main application image is signed with the digital signature, the bootloader may perform additional authentication steps. This involves verification of the signature against a trusted key or to certify it to ensure that the application is authentic and hasn't been modified. Next, we have the main application execution. Once the bootloader has successfully loaded and authenticated the main application, it transfers control to the application in trip 1. The main application then begins its execution taking over the device's functionality. It has bootloader update as an option. In some cases, the bootloader itself may be updatable. If an updated bootloader is available, the main application can initiate the update process by requesting the new bootloader image or updating a bootloader in memory. It's important to note that the boot flow of this fire bootloader can vary depending upon the configuration and customization implemented by the device manufacturer or system developer. These steps outlined above provide a general understanding of the typical boot flow for the fire-based system. Moving on to the MCU boot, we'll discuss in this slide some of the features of the MCU boot. It has secure boot, firmware update, cryptographic verification, better than the Fire Bootloader, flexible configuration, error handling and recovery, time for resistance and compatibility, and integration possibilities with other microprocessor, microcontrollers and the RTOs, like the Zafire RTOs. I will discuss about the MCU boot. The MCU boot engine is an open source bootloader specifically designed for microcontrollers and is often used in the fire-based systems. The high-level overview boot flow of the MCU boot is from the power-on or reset. When the MCU is power-on or reset, the MCU bootloaders start executing a predefined memory address, typically the bootloaders, in three points. Then it jumps through the bootloader initialization. MCU boot initializes the essential hardware components such as clock, memory, peripherals required for the bootloader's operation. Then it scores for bootloader source selection. MCU boot determines the source from which to load the main application. This can be based on predefined configuration options or runtime checks depending upon how the system is configured. Then it scores for the primary slot execution. MCU boot initially moves the primary application slot, assuming its contents are valid and authenticated application image. Then it scores for the image validation. MCU boot validates the image in the primary application slot using cryptographic signatures or checksum. It verifies the integrity and authenticity of the image to ensure it hasn't been tampered with. Then it's based on the result of the image validation MCU boot determines the boot execution. Every primary application image is valid and authenticated. MCU boot transfers control to the primary applications in three points and the application begins executed. If the application image is invalid or not present, MCU boot falls back to the secondary application slot. The secondary slot execution will discuss about the secondary slot execution. If the primary slot is invalid or doesn't contain a valid application, MCU boots the secondary application slot. Image swap is an optional feature. If the secondary slot contains a valid and authenticated application image, MCU boot can perform an image swap to make the secondary slot the new primary slot. This allows seamless and atomic updates of the application. If there is an optional image update feature as well, MCU boot provides functionality to update the application image in either the primary or secondary slot. The update process can be initiated by the main application or through external means such as over-the-air update mechanism. So in this case, it's important to note that the MCU boot flow is highly configurable and customizable, allowing for various strategies in terms of image storage, security features, and update mechanism. The boot flow described just provides a general understanding of the typical boot flow in the MCU boot. But actual implementation detail may vary depending upon the specific MCU or platform and the configuration chosen for the MCU boot flow. So in this slide, we'll discuss about the integration process of the Fire Boot Floater and MCU. Integrating this Fire Boot Floater with MCU boot involves configuring and building both components to work together seamlessly. So as a step-by-step guide to help you with the integration process, first we have to set up the development environment, install the required development tools including Fire and MCU boot. Set up the necessary build systems such as Themeek to compile the bootloader and the Fire application. Next step is to configure the Fire Boot Floater. Identify the specific Fire Boot Floater configuration you want to use, such as the one provided by the Fire's samples bootloader directory. Customize the bootloader configuration according to your specific requirements. This may include selecting the appropriate boot source, defining slot sizes, enabling future boot features, configuring communication interfaces and more. Integrate MCU boot with the Fire Boot. Show that MCU boot is installed and available in your development environment. Configure MCU boot integration into the Fire Boot loader configuration file. This typically involves defining the MCU boot every department. Specifying the required MCU boot APIs and configuring the slot file. Next step is the integration process of the Fire Boot loader and MCU boot is building the bootloader and the Fire application. Build is a Fire Boot loader using the Fire Boot system. This will compile the bootloader code and generate the bootloader image file. Build is a Fire application that you want to boot using the bootloader, ensuring that the application will be built with the necessary MCU boot integration and may require configuration options. Flash the bootloader and the Fire application. Flash the compile bootloader image to the appropriate memory location on your target. The flashing process may vary depending upon your specific hardware and tools. Flash is a Fire application image ensuring that it is placed in the appropriate memory location. According to this load layout, define the boot loader. Verify the integration power on or reset the device to observe the boot process and ensure that the bootloader execute successfully. Verify it is a Fire application image and transfers control to the application input. Next step and the last step is to test and hydrate where you get the integrated the Fire bootloader and MCU boot as functioning as expected. Perform tests to verify secure boot functionality. Image updates and other desired features. Hydrate on the integration and configuration as needed. These are your specific requirements and feedback on tests. You can see some code snippet in the slides as said how to proceed with the integration process. We have to develop a boot support packet for our boot as per our own configuration. In this slide, we can see a basic bootloader flow chart. So as we know as the boot loader initiative the initialization of hardware starts and it's load user config data from bootloader customizing area then configure clocks, peripherals and memory. If any update is required then the boot pin got asserted and it can go for the firmware update. Otherwise, it will check if the user app is valid or not to check some or through some cryptography verification and then it can go for direct boot or through the timeout. If we call as the boot time. So in this slide we will discuss about the benefits of integrating the Fire bootloader and MCU boot. Integrating the Fire bootloader with MCU boot brings single benefits to the development and deployment of embedded system. There are some advantages of combining these two options. First advantage is secure boot. MCU boot provides sober security features such as proof-to-graphic image authentication and secure boot capabilities. By integrating MCU boot with the Fire bootloader you can enhance the security of the system by ensuring that only trusted and authenticated firmware images are recreated. Next advantage is dual image slots. MCU boot's dual image slot strategy allows for seamless firmware updates and reliable fallback mechanism. By integrating this feature into the Fire bootloader you gain the ability to perform safe and atomic image swap ensuring that your device can always boot into a known boot firmware image. Next advantage is efficient image updates. MCU boot supports in-place image updates allowing you to update the firmware without requiring a full chip erase. This results in faster and more efficient updates preserving critical data and configuration settings during the update process. Next advantage is over-the-air updates. By integrating MCU boot with the Fire bootloader you can leverage the over-the-air update mechanism to remotely update and manage firmware on your device. This enables convenient and efficient firmware updates over wireless networks reducing maintenance costs and improving device management. Flexibility and portability improve by this integration and MCU boot's hardware extraction layer allows for easy porting of different microcontroller platforms. While the Fire's smaller and configurable architecture provides flexibility to adapt to various use cases. Next advantage is open source and community support. Boots of Fire and MCU boot are open source projects with active communities. Integrating these components allow you to leverage the collective knowledge, expertise and support from the developer community ensuring ongoing maintenance, bug fixes and security updates. Another advantage of this integration is extensibility and customization. Integrating the Fire bootloader with MCU boot provides a foundation for extensibility and customization. You can build upon the bootloader stack to add custom features and security mechanisms to your requirements and integrate additional functionality based on your application's needs. By integrating this Fire bootloader with MCU boot you can benefit from a powerful and secure bootloader solution with enhanced update capabilities improve security and the flexibility to adapt to different hardware platforms and development scenarios. Now I'll pass you over to my colleague Priya Dixit to take you further in this session. Thanks Abzal. Hello everyone. My name is Priya Dixit and I work as a staff engineer at Samsung Semiconductor India Research. I will continue from secure booting in Zifier RTOS. We will first understand PKI that is a public key infrastructure and digital signatures to understand secure boot and to get the idea about secure booting. Public key infrastructure is used to ensure the authenticity and the integrity of systems boot sequence using cryptographic keys. These cryptographic keys are used in algorithm to encrypt and decrypt data or for signing and verifying which can be a symmetric or symmetric. Here in symmetric exceptions we use a single key to encrypt and decrypt data while in asymmetric encryption we use two different keys to encrypt and decrypt. For implementing secure boot we preferably use asymmetric cryptography that has two types of keys private key and public key as the key management is easy in this case. So here the private key is kept secret and is securely held by the trusted system whereas the public key is derived from the private key that is distributed. Now let's talk about digital signature. So a digital signature is a mechanism that is used to verify the authenticity of software using cryptographic keys. For secure boot the digital signature is created by using a private key that is responsible for signing the software and the digital signature and then verified using the corresponding public key which is typically embedded into the system's firmware or is securely stored in a hardware component such as TPM. So secure boot is a mechanism where we verify the digital signature of bootloader and OS before executing. So when the part of the system is signed using a private key the corresponding public key is used to verify the signature and if this verification process succeeds this will ensure that the content of the file has not been modified since it was signed. This way using cryptographic keys and digital signature we establish a chain of trust ensuring like the boot is secure also this ensures that the hardware is trusted and authorized with software components which help in protecting against unauthorized modifications and forms of foundation for establishing a secure environment. In the case of firmware that initiate the boot process using private key we sign the cryptographic hash of the firmware and bootloader that will generate digital signatures. So as the boot progresses the firmware verifies the digital signature of the component it loads in the file that is stored in the firmware. The public keys are pre-installed in the system if the digital signatures are valid then the boot process will continue but if the digital signature is not valid the firmware holds the boot process signaling that something is fishy. Then the verified bootloader will initialize the operating system the digital signature of OS is verified and if it is secure then it is allowed to proceed otherwise the boot process is halted. So when secure boot is enabled the firmware will verify the digital signature of each of the executable file from the firmware to bootloader then to operating system before allowing them to run and this will guarantee that the executables are from trusted source and has not been modified. Here we see a term have which means high assurance boot library and this is a secure boot library for IMX processors that are designed to protect the system against various forms of attacks. This can be done by establishing a chain of trust from initial power on of the system to the operating system execution so that each component loaded during the boot process is cryptographically signed and has not been modified. This is an example of the system which ensures that the system start up securely and only runs authorized and verified software components providing a foundation of trust. In secure boot the first stage bootloader is programmed into non writable storage location on the device. The first stage bootloader then calculate the hash value of the second stage bootloader and verify it against this stored hash value for the bootloader. Similarly depending on the hierarchy for example if we have two stage bootloader then we will repeat this process and verify this in the same way. Then we will verify if the operating system is working or is valid and the operating in the sequence are valid. So here in chain we validated each layer and once it is trusted we proceed to validate the next layer in the chain. We will now check how secure boot is implemented in MCU boot. So Zafire RTOS is PSA certified with trusted firmware and implementation that is based on root of trust architecture in the case that we can use directly in integration of Zafire after TFM integration. Also there is a choice among three isolation levels based on the boundary rigidness between a secure and non secure region. Along with this Zafire provide the support for trusted execution environment TWE using TPM. And here TPM is a trusted platform module that provides hardware security module that provide storage of cryptographic keys and other security related data to verify the boot related informations. In MCU boot the binary image suffix with TLV pair that is type length value pairs. This is where we store the information about how the image is signed. Also here we can add metadata for custom data to add to an image. Here we can see that hash key value is defined and for example here we are using 0x02 as the public key. So based on the configurations we choose the security of MCU boot will get affected. For example we can use SHU 256 base validation to check for image corruption. There are many macros available to choose from the digital signatures like config boot signature type RSA and config boot signature type ECDSAP 256 which will control the type of signature the MCU boot uses to verify the image. And if we do not define any signature algorithm then the image is not protected against the intentional modification but it will just act as a checksum preventing a corrupted image from booting. Also there is one macro config boot validate slot that ensures that MCU boot validates the signature of the image on every boot. Although this feature makes the booting process a bit lengthy but it always verifies that the running image is trusted. With this secure boot process in place we can check during reboot will identify the unauthorized executables and prevent it from running further. And in background it may initiate remedial actions. The firmware upgrade process in Zephyr RTOS is secure procedure that ensures the installation of updated firmware on the target device by writing the new image to the flash and replacing the previous image. So whenever some new features are added to the firmware to do any bug fixes then to update the system with those changes we do a firmware upgrade by preparing a new firmware image. So on a regular interval we can check if new firmware update is available for the device or not. Here we may use versioning to check if any higher version image for the firmware update is available. If the new firmware image is available then we can proceed to download it securely or we can in regular interval schedule the recheck to check if any higher version image has come. So this new feature, this new firmware image is then securely downloaded to the target device through interfaces like UART or SD card or via cloud we can download the new firmware image to some partition or to some partition in the target device. We will then verify the firmware using digital signatures or checksum to ensure that it has not been corrupted during transfer before applying the update. So here also the firmware is signed using private key and verification is done by public key as in case of secure boot. So Zafair Atoz leverage MCU boot to do firmware update. Here MCU boot will conduct further verification of image and perform integrity checks. And if the new firmware image passes these checks then MCU boot safely updates the image guaranteeing a secure and reliable firmware upgrade. And if this fails we may try to initiate the upgrade again because there might be some issues with download or there may be some issue that was there but it might have been solved now. So once the device is authenticated we can download the image to the secondary slot of the flash from where it will start installing the fresh firmware upgrade. So there are many direct APIs we can call for example a call to boot request upgrade will perform firmware upgrade on the next boot. So let's now talk about rollback protection and the advantages it offers. So rollback protection is used to perform the upgrades in a fault tolerant manner and it is also used to recover the system if a bad firmware image is installed. So this is a essential security feature provided by the Zafair Atoz to ensure that once the device has been upgraded to a specific version it cannot be reverted that is less secure. So Zafair Atoz implements rollback protection via MCU boot which includes a firmware image storage mechanism here we maintain the record of the firmware image versions we have installed along with this the associated metadata we also record so when performing the firmware upgrade the MCU boot checks the version and metadata of the currently installed firmware and if the incoming firmware image is older or has less secure metadata then we reject that update and this will prevent the rollback. There is a macro config boot upgrade only that controls how upgrades are performed. So if this macro is unset MCU boot uses a swapping algorithm to exchange the new upgraded image with the old image allowing an easy reward to the system if the image is not booting and if this macro is enabled the image will overwrite the old image and if the new image does not boot there is no fallback image. As we see here the major steps remain same for the firmware upgrade process but the rollback protection provides an additional benefit of switching to the previous secure firmware image in case the new firmware that is downloaded is not working properly. So rollback protection is the FireArtox guarantees that the device will only run on the latest and more secure firmware versions. Bootloader recovery. In the events of bootloader corruption or failures the FireArtox offers a method to restore ensuring a continued operation of the device. So bootloader recovery process uses secondary bootloader or dedicated recovery mode that allows the device to boot again. So as FireArtox provides tools such as DFU that is device firmware upgrade and SWD that is serial via debug interface that helps in reflashing the bootloader firmware or performing other recovery procedures to restore the device boot functionality. So depending on specific implementation there are various mechanism to recover from the failure including the options such as falling back to the known image or restoring the bootloader to a default or factory state initiating a firmware update using the trusted and validated image or reconfiguring the bootloader settings or parameters. A threat model help us in identifying potential adversaries by analyzing different threat scenarios we can develop an effective security measure. Common threats include unauthorized access, insider threats from individuals with privileged access and we can have the firmware level attacks, the supplier chain attacks physical tampering and denial of service attacks. Considering these threats prior help us to prioritize security efforts and implement appropriate measures for enhancing the overall system security. So following are the best practices that can be used for integrating secure Zafire bootloader and MCU boot into the system. Understand the requirement for integration process and optimal performance. Develop a secure boot architecture that incorporates the Zafire bootloader and MCU boot using secure boot stages like using cryptographic signatures key management and secure storage of firmware images and verification data. Implement a secure firmware transferred by using secure channels and protocols for transferring firmware image sources to the target device as discussed in the previous slides and develop a secure mechanism for updating firmware. Implement a firmware verification and authentication mechanism within the bootloader. Implement firmware verification and then we can also deploy the error handling last is to validate thoroughly the test of integration of Zafire bootloader and MCU boot by doing rigorous testing to ensure that the boot process securely enabling firmware updates roll gas protections and overall system security. Future development so following are the some of the future scopes for integrating Zafire bootloader and MCU boot system security. Advancement of hardware security like integration of secure elements or trusted execution environments directly into the microcontroller. Cryptographic algorithms may evolve ensuring stronger encryption. Machine learning and artificial intelligence can be used to identify threats and may provide advanced protection solutions. There can be an enhancement in the security of OT updates using the macro using some macros over a more secure channel and providing additional verification mechanism. With growing concerns over data privacy we may include a stronger data protection methods in future. Future developments may involve real-time monitoring by providing the timely alerts and responses to the security builds. In the future we may provide tools guidelines and best practices that promote a secure system design and development. Thank you for attending the presentation. Please let us know if you have any questions. Thank you.