 Okay, now you had the first hand on the SBSFU package. Let's see what is this SBSFU package and have an overview about what it can do. So here is the agenda of this presentation. So we will first have a more theoretical presentation about what is a secure boot and a secure firmware update. And then I will present you what is the package, how it addresses the security and the protections. Then also a bit about the cryptography used in this package. Also a quick overview about the architecture, some advanced features and the conclusion. So let's go. Secure boot principle. So what is a secure boot? It's a code executed after reset that verifies the application firmware is genuine before launching it or not. This is really the basic of what is doing a secure boot. So after reset, we launch the secure boot. The secure boot reads the content of the firmware and checks the integrity and the authenticity of this firmware. And if it's okay, it loads the application. So what makes a secure boot secure? First, the secure boot should be the only possible code executed after reset. This means that the address where the code is launched should be always the same. And after reset, we shouldn't be able to launch directly the application, for instance. So this is what we call the boot lock. The second condition is that the secure boot code is immutable so that it cannot be modified in any manner. So here also, secure boot is locked. It's like ROM code, for instance. And all these, well, these two conditions, we call them the root of trust. This means that if you are sure that after reset, the code jumped to the secure boot and the secure boot cannot be modified, then you have your root of trust. And then you can launch authentication and do the further actions. Now how these integrity and authenticity are checked? Integrity is checked thanks to a hash. The secure boot reads the whole application firmware to generate this hash and this hash needs to be compared to a reference. The use of a hash is really important because there is no way when you have a hash result, which is called also a digest of a firmware, to change the firmware to get the same value at the opposite of a CRC, for example. So the use of a hash is really important to have this integrity check. The authenticity is checked thanks to a signature. Usually we use the hash value and we sign it. This signature is generated thanks to a private key and the signature is checked thanks to the associated public key. You could see this in the MOOC basic of cryptography, for instance. So hash value and signature value need to be provided with the firmware. This is the condition to be able for the secure boot to be able to check this firmware. These two values are stored in a container that is called either metadata or header. There is no need to encrypt the metadata thanks to this signature mechanism that it cannot be modified. Here is the introduction of this metadata. Usually it is beside the application before or after in the address range. And it provides the necessary information to the secure boot to perform this checking. How this metadata is built? So you start from your application firmware binary. You need to do this in a secure room because you have a private key. So this private key needs to be in a safe place. And so all actions using this private key should be done in a safe place. Then you use a hash algorithm to create a digest of your firmware. And this digest is assigned thanks to a symmetric algorithm like RSA or ACDSA signature mechanism. And thanks to this you generate the metadata. So how the secure boot verifies the signature? You have in your internal flash the secure boot, the metadata and the application firmware. And the secure boot embeds the public key to be able to verify the signature. So at startup the secure boot reads the content of the firmware, the whole content to compute the digest of this firmware. It is using the corresponding signature verification using the public key as input and the metadata also as input. And this algorithm is able to provide the status okay or not okay. Depending on what you have provided, if you modify here one bit, the hash will change completely and the digest will not correspond to the one in the metadata. And if you change the signature obviously it will not fit with the firmware. So anything modified here or there will lead to an authentic firmware and a failure. Now let's go to the second step which is the secure firmware update principle. We defined what is a secure boot, how it checks the application, thanks to this metadata. Now let's see how we can update this application firmware in a secure way that is called secure firmware update. Secure firmware update principle, first you need to transmit your update file to the target in some way. This update contains an application firmware and the associated metadata. With the metadata the secure boot can check the application firmware integrity and authenticity and if check is okay the secure boot can install the new firmware. So first step, we create an update file. You have developed a new update of your application firmware. Then you need to create a digest of this firmware, sign it and generate the metadata. The concatenation of this metadata and the application firmware is the update file. This update file will be transmitted to the target. So second step, transmit update file to the target. Two possible ways, first the file is sent remotely. This is the case of many IOTs that have a connection to a server. And the second possible way is the transmission thanks to a local connection like UR2SB SD card. Anything that is local to the device. In all cases the update file needs to be written on the target flash with a loader. So the loader can be part of the secure boot. It can be a standalone application or part of the application firmware. Third step, installation of the update. So the secure boot can now access to the update file. The secure boot will check integrity, authenticity thanks to the metadata. If the check is okay, the update file can be installed. So how the new firmware can replace the old one. When using the local transfer, the loader can be in the secure boot or in a standalone application. Or even the application itself. If the loader is located in a secure boot or standalone, it can first erase the application and then load a new one. If the loader is in the application itself, you need a spare space in the flash to first write the update image obviously. In remote transfer, the most common case is that it's the application that connects to the server. So this is the rule of the application to download the new firmware and to write it locally. Yes, the new firmware needs to be stored locally while the current firmware is still running. So that's why we need a second slot. So that's why we need two slots. One slot for storing the active firmware and one slot for storing the downloaded firmware. So here is a local update example. We have our application and secure boot and metadata. Here we have the update computer that is connected directly locally to the target with serial communication. The secure boot embeds the loader. And first thing, once the communication has been established and the secure boot received a request to make the update, it erase the old firmware or just erase the content of the flash. And then it can transfer the update through this communication. So transfer the metadata and the application firmware and write them to the flash. Once this done, the secure boot can check integrity and authenticity of this new firmware and erase it if it fails. Here is a remote update example. So now we have still our application firmware and secure boot metadata. And we have an active slot and an update slot or download slot. Now the server is connected to the application or application is connected to the server via a remote link. And so the loader is inside the application which is able to write in the second slot the metadata and the application firmware. Once this has been done, the application firmware can perform a reset to give back the hand to the secure boot and to start the installation of the new firmware. So after reset, the secure boot is detecting the new firmware. It is checking obviously the new firmware. And then once it is checked okay, it is installed. Thanks for example to a swap process. Update firmware encryption. So as the firmware is most of the time a very valuable asset, you need to encrypt it because it may go to unsafe location. So this encryption of the firmware must be performed thanks to a symmetric key. And this symmetric key is used to encrypt the firmware when we generate the update file and it is used to decrypt the firmware when we install the update. So the same symmetric key is required both in the secure room and in the secure boot. So how to create? We have our firmware generated and our update firmware. Our secure room with still our private key. And now we have an AES key. So that this AES key performs the encryption of the firmware. And we still have to get the digest of the firmware unencrypted to be able to generate the signature. And the update file now is the metadata and the encrypted application firmware. So local update with encryption. Now we have our AES key in the secure boot. We update thanks to the loader in the secure boot. We erase the old firmware. We transfer the update with the encrypted firmware. Here we have decrypted the new firmware. And then the secure boot can check integrity and authenticity. And again erase if it fails. And launch application obviously if it's okay. A little word about key management. We could see we need an asymmetric keypad to generate and check the signature. And a symmetric key to encrypt and decrypt the firmware. So the asymmetric keypad can be generated by a tool like OpenSSL. The private key is used to sign the firmware. And it has to be kept in the safe place or in the secure room as we said. And the public key is used to check the signature. So it is provisioned on the device and must stay immutable. So the key is public but it is mandatory to ensure this key cannot be changed. Otherwise the authentication is no more ensured. The symmetric key can be generated with a random. It is used to encrypt and decrypt the firmware. And it needs to be kept in the safe place and provisioned on the device. So how to protect these keys? The private key and symmetric key must be stored in the safe place by the OEM as I said. Public key is provisioned with the secure boot. So knowledge is not a problem. It's public but it must remain immutable. And the symmetric key is provisioned also with the secure boot. And it must remain secret. So it needs to be protected inside the secure boot. And to ensure this protection we must use the isolation mechanism. So we will see later how we perform this isolation. So in conclusion we have seen the basic principle used in the secure boot and secure firmware update. We can see this involves many concepts that require a lot of development. If you want to create your own secure boot from scratch. Also, NCM32 family, you have a lot of different security mechanisms that need to be used to ensure the maximum security. To address this complexity of both manage different families and the complexity of the secure boot itself. We propose the Xcube SBSFU package. So let's see what is this package in a glance. So the package is an implementation of secure boot and secure firmware update. It addresses nearly all STM32 families except old one, F0, F1, F2 and F3. It is still possible to make your own porting on these targets but we don't support them directly. And the SBSFU takes into account the STM32 family diversity in terms of protection mechanism mainly. And the SBSFU is provided to help ST customers developing their own SBSFU adapted to their level of security requirements. An important notice, SBSFU is provided as a reference code to demonstrate state-of-the-art usage of STM32 security protection mechanism. It is a starting point for OEMs to develop their own secure boot and secure firmware update application as a function of their product security requirement level. This means that this package is not ready to use a package. You need to understand what it is doing to adapt to your own constraints and to your own security requirements. In a nutshell, this package is a standalone package containing a full functional secure boot and secure firmware update examples for each supported STM32 family. Current version is 2.4.0 in date of September 2020. We have 34 examples available for all these boards, so for some targets we have more than one example. And this package is provided with some documentation. First, you have an introduction to microcontroller security, which is a must read, I would say. Then, related to this package, you have the getting started that explains all what you need to know about this package and an integration guide that is giving some tips to mainly make a porting or adapt the package to your own target. The package content you can see here from the top, it is provided with all the necessary drivers for the STM32 family supported. The middleware is mainly what is common to any target, so the cryptographic key management service, secure engine we will see, and also the STSafe driver for the WB, and also the cryptographic algorithm from third party. And in the project here, you have all the boards supported. So you can see that, for example, in L4 family, we support 1, 2, 3, and 4, 5 targets. Now, let's see how SBSFU addresses security requirements. So SBSFU supports all protection mechanisms available in STM32 in the family that is addressed. It ensures the confidentiality of the firmware. It ensures the unique entry point, the immutability of the secure boot code and isolation mechanism to protect against inner attacks. Confidentiality, so it's to prevent external access to the firmware. So this is achieved thanks to RDP level 2, where we have no more JTAG access. This RDP level 2 is set up using option bytes. And once it's done, obviously it's still possible to use the SBSFU for making updates. And SBSFU ensures that at each boot, the RDP configuration is set up as expected. The entry point is to ensure that after reset, we always boot at the same address. This is also ensured thanks to RDP level 2. This RDP level 2 deactivates the ability to boot on system bootloader or on internal RAM. Code immutability, the immutability is ensured thanks to the right protection. And this right protection is set up thanks to option bytes also. On the selection of sectors and RDP level 2 makes this option byte no more changeable. This is why we get the code, how we get the code immutability. Regarding RDP usage, so as you could see RDP level 2 ensures confidentiality, the boot lock and immutability. And recent STM32 families, you could use RDP level 1 with some limitations. For instance, thanks to the implementation of the secure memory on the G0, G4 and H7, the combination of this secure memory and RDP level 1 brings the impossibility to connect with a debugger. And the inability to change the content of the secure memory. So the confidentiality in that case is ensured thanks to the JTAG deactivation. The unique boot entry is ensured thanks to the boot lock on G0 and G4. And immutability is ensured thanks to the secure memory. So cryptography, we use either our X-Cube Crypto libraries or Open Source MBTLS Crypto. The isolation of the symmetric key that is very important is addressed using the most efficient protection we have on different STM32. So on L0 and L4 it is mainly protected thanks to the firewall and the PCROP. On the F4, F7 and L1 we use the MPU privilege mode to protect it. On H7, G0 and G4 we use the PCROP MPU privilege during the secure boot execution. And then it is the secure memory that protects this key. Once you jump on the application, the code of the secure boot is no more visible. And on WB, the protection is made thanks to the M0 core, isolated from the M4 core. Additional security mechanism handled by the SB-SFU, so the temporal protection. The watchdog, disabling of debug GPIOs and disabling of DMA clocks to enforce MPU protection. So all this can be activated or deactivated depending on your target requirements. SB-SFU security mechanism handling, so all the mechanisms I talked about are handled by SB-SFU. So at each boot we have all static protection, so basically the option byte configuration that are checked. And the dynamic protection that are set up according to the expected configuration you made. From version 2.2, we introduced a flow control mechanism that is able to... That is a countermeasure against power glitch attack. So this is what we call a control flow mechanism. You can see if you want more information, you can go in the code and see how it works. It's a standard way to do. So in conclusion, it's really important to handle all the security mechanisms in the proper way. And SB-SFU provides this ability to address all this. And it also ensures that all these mechanisms are properly set up. So let's see now a bit of cryptography addressed by SB-SFU. After security setup, this cryptography we are sure can be executed in a secure way. And the algorithm used our SHA-256 and we use elliptic curve P256 ECDSA. And confidentiality is addressed to ASCBC in 128-bit key. We use a two-steps authentication. This means that the first step, we authenticate the metadata. And once authenticated, we can check simply the digest that is included in this metadata. So here you have here the metadata containing the version, the firmware size. And then the application digest is put in the metadata. And this metadata is signed. So we need to create a metadata digest and signed this metadata. This is the SB-SFU header in a simplified way, but this is the main mechanism used. So this is the first step. We signed the information and most important, the version and the digest. And the size also is important. And so when we start, the SB-SFU is starting, the authentication check first authenticates the metadata. So if metadata is okay, we can go on. We can check the application firmware digest. So we get a digest of the application firmware. And we can compare to this value that is authentic. And then we can decide if the application is genuine or not. So now let's see a bit more about SB-SFU architecture. The SB-SFU is actually split in two components, the secure engine and the SB-SFU application. You could see this AC Corbin in the first hand zone. The secure engine is a framework to handle critical function in an isolated environment. It's composed of an API that defines that service provided and the core that implements these services. So basically inside the SB-SFU, if we expand this, we have a part dedicated to the secure engine that executes a crypto operation and store the keys. So the keys are located here. And there is a hardware mechanism that makes sure that we call the API through this interface and the API is going through a gate so that we are sure that we cannot directly call anything directly from the SB-SFU application or even from the user application itself. This is a way to isolate all the critical operations. The package architecture, so you have SB-SFU application with all the features of the implemented. The secure engine with the interface, the call gate entry point and the different services. You have the user application example for each target. And you have also a standalone fiammarian loader example provided. And then all this is based on the HL API and the port package for all the chips and the boards. So nuclear boards and some discovery boards. Here is an example of two-image startup sequence. Two-image means here we need the update slot. So compared to only one slot when we have one image. So when we reset, we go to SB-SFU entry point. First, we check static protection, activate dynamic protections. And so once this is done, we are in a secure environment. So we check if there was a request for fiammarian download using local loader if it's inside the SB-SFU. If yes, then it is downloaded in the slot download part and then it resets. If there is no fiammarian download, we check if there was already a download fiammar. So here we download a fiammar. So reset is done and we come here and the new fiammar is to be installed. And so in that case, we check the new fiammar and install it. Thanks to the swap process and reset again. And third part, we have a new fiammar installed. It's verified if it's authentic. We launch the application and if not, we invalidate and erase the fiammar and go back possibly in the download a new fiammar using local, for instance. So checking static security step, which is very important. We are checking the option bytes. SB-SFU provides an easy way to activate this protection through defines. We will see this in the following hands on. Just after booting, we ensure option bytes are in expected states. And the SB-SFU is implementing two behaviors. Development mode where we program option bytes to their expected value. If they are not, and the production mode where the option bytes are supposed to be already programmed on the production line. So if it's not programmed as expected, then the SB-SFU is blocked. So static protection handle, RDP, write protect, P0, secure memory and boot lock, which are all option bytes. The dynamic security setting, so after all the static protection is checked, then the SB-SFU is activating the NPU, the firewall if we are on L4 and L0. The watchdog tamper and also disabling GPIO and DMA clock, depending on the configuration you set up. And each protection, as I said, can be enabled or disabled through compilation flag. Here is a mapping of the STM32L476 that is used during the hands on. You can see the vector table of the SB-SFU, the secure engine, the secure engine interface and the SB-SFU. And you have here the download slot with the download image header and the download image. Small space here, active image header and active image. Then you have a swap area that is used to be able to swap the two image during installation in a secure way, so that you can continue the swapping even if a reset occurred for instance. And then you have some space for user data. Here are all the protections used in detail. So this is the flash mapping, this is the SRAM mapping. All this is detailed in the user manual getting started, UM-2262. So you can see for each region of the user flash what kind of protection is used. So here you can see that the firewall is used to protect the keys, the secure engine, the header and also the RAM used by the secure engine. Some figures, so in the footprint the SB-SFU is taking between 32 and 56 kilobytes. It can go over depending on the features you are adding, like for example the key store feature. In RAM it is using 4K bytes, if you are using the firewall you cannot recover these 4K bytes, but in other case you can recover them after the secure boot has given hand to the application. In boot time, well the boot time mainly depends on the crypto operation, it's about 90% of the boot time. So it highly depends on the target performance and also available hardware accelerator. So order of magnitude is between 100ms and 1s, but you can go faster using a hardware accelerator for instance. The update time it depends mainly on the download interface and the flash writing speed. You can expect that a single image update is much faster than the real image where we are doing a swap. SB-SFU features, so in the SB-SFU package we provide also a bit more advanced features like a key management service that is an added service in the secure engine to manage static and dynamic key storage. So it's basically a key store. The new keys can be provisioned with a mechanism similar to firmware data. We support also a secure element, ST-Safe A110, and this ST-Safe is used to validate the authentication key. So we have a certificate chain, we implement a certificate chain using this ST-Safe and the certificates are checked inside the SB-SFU. We also support external flash, so through QSPI or Octospi. If you have a simple external flash, we can use it for the download slots. And if the STM32 is supporting underfly decoding or TFDec, then we can use the external flash to store the active application. We also support a partial update, so this is the ability to update just a part of the flash. Also there are in the latest version the support of different update options. So the legacy one, which is from 2.3 that is using a swap area, but no rollback is authorized. There is a second mode, which is called no swap. So we gained the swap area in terms of flash memory footprint, which could be useful in some cases. So the installation is not using a decryption in place. Obviously in that case, we just installed a new firmware that is encrypted. We decrypt underfly and install the new application. So before installation, obviously a first decryption without any writing is done to be able to check the digest of the decrypted firmware. But in that case, we don't support any partial firmware update. And the last mode is the self-test user application of the user application before complete validation. So here we swap the application during the install. Then the new fresh application performs a self-test. So basically it's connecting to a server to check if everything is okay. And if it's okay, it's calling an API called ValidateFirmware, which makes this firmware valid. So something is changed in the header of the firmware to say, okay, this firmware is valid. And if the test failed, the application should force a reset. And then the SBCU detects that the application was not validated. And then it's doing a rollback to the previous image that is supposed to be working fine. A multi-slot, in order to manage a multi-core device where we have different firmwares that are independent, we support now up to three active slots and also up to three download slots with the ability to use only one download slot depending on the constraints of your platform. When you have more than one slot, SBCU is checking authenticity and integrity of each slot at startup. And it jumps to the first valid slot in numerical order or to a slot that is defined as a master slot. So in conclusion, SBCU is supporting all recent STM32 families. Only exception concerns the families based on the Cortex M33. So the introduction of trust zone and the support of the RMTFM framework that you will see in the next part of this workshop leads to change the secure boot strategy on STM32 L5. So the L5 still supports something equivalent to the SBCU SBCU secure boot secure firmware update. But it is based on the open source MCU boot that is used by TFM framework actually. Another point, SBCU code has been audited by an external lab that gives good confidence in the code we provide. As you could see, SBCU provides many different configurations to fit to various setups. It is maintained and new features still come regularly. And also we support customers with their implementation. So thank you for your attention and now let's go to the next hands-on on SBCU.