 Now, we have an idea of the basic principles of a secure bootloader. The next we will talk about secure former update. Why secure former update? Former update is a feature very common in IoT products. The reason of firmware update could be bug fixes, adding new product functionalities, etc. It is also a very necessary feature in order to keep improving the security protection along with the product lifecycle. In case any new vulnerability is discovered. However, adding the former update capability also introduce new services to attacks. Malware injections through update procedure becomes possible. Former content could be jeopardized or leaked during the update procedure. Device former could be downgraded to an older version where no vulnerabilities to exist. A secure former update shall mitigate those risks brought by the update feature itself. What should be protected during former update? First, former integrity and authenticity. Secure former update shall always verify the integrity and authenticity of the new former to be downloaded and installed in the device. Second, former confidentiality. Former content shall not be exposed to and authorize the party because of former update. Former content cannot be transmitted in clear in the communication channel for upgrade. Third, avoid former version downgrading. The secure former update shall also have anti-rollback capability to avoid device former being replaced by an older version of the former, which also has valid authentication data. A secure former update starts with the capability of updating the existing application inside the device. Devices need to be able to download the data of the new former through a communication port. Data might be transmitted through a wired or wireless communication channel. Depending on the application requirement, different communication port or method could be used. Former download can be a feature to be included in the bootloader. Application might also have the capability to download the former as well. That possibility is more linked to the constraints of the system, such as the memory space and so on. This is an example of the flash layout for the application with the bootloader. In case there is just one slot for the active application, most likely the download of new version will happen from the bootloader code. The bootloader would download the new version, verify the new version and replace the active application by the new one. There's also the case that there were two slots for the application, one for the active application slot and the other slot to hold the new version to be downloaded. In such case, the download of new version could happen from both bootloader or from the active application. And then after the verification of this new image, the active slot will be replaced by the new version of the former. One key responsibility of SQLFormerUpdate is to ensure the former authenticity. Former authentication happened during former update is similar to the same concept that we explained in SQL Bootloader. The goal is to verify the authenticity of the new version of former before installing it. The integrity of former will also be covered if it is authenticated. A new version of former shall come along with a set of metadata which includes necessary information for authentication, such as the former hash, signature of the metadata, other information describing the former itself, for example, the size, version, etc. The verification procedure will verify the signature of the metadata itself as well as the digest of the former content. Confidentiality is also a concern of the SQLFormerUpdate. To achieve the former confidentiality during former update, one option is to use a SQL Communication channel. For example, an IoT device can establish a SQL Communication channel with the server using TRS. All the former data transmitted afterwards will be encrypted. One concern of this approach is that you need to trust the former update server where your former could be originally uploaded in clear. How the former is stored on the server is out of your control. Another option is to have the former encrypted with predefined symmetry before uploading for update service. The former will always be stored on the server in encrypted format and stays encrypted during the downloading procedure regardless of the communication channel encryption state. Of course, the symmetric key to decrypt the former need to be provisioned in the device beforehand and that symmetric key need to be protected for its confidentiality and integrity. Then let's take a look at how we can protect the encryption key on SM32. First, RDP level 1 and 2, which is available on most of the SM32 family will protect the symmetric key from debug port access. And WRP can also avoid the key data to be modified accidentally or intentionally. Together with RDP2, key integrity can be assured. Product families with PCrop feature can also protect the key from being read through debug port or read by code as data. But of course, key content can still be retrieved by executing the code inside Visorab area. Then isolation mechanism can be applied to further protect the key from being accessed by application to avoid any key exposure due to application vulnerabilities. Different isolation mechanisms on SM32 can be used to protect the encryption key. On L0 and L4, Firewall is a feature that can be activated after power on to protect the key data and its usage to prevent any access by the code outside Firewall area, including book loader code itself and the application code. And it is still possible for application to call the former decryption service from Firewall protected area even after execution already jumped from bootloader to application code. On G0, G4, H7, secure bootloader, including the former encryption key can be put inside the secures and memory area which will not be accessible anymore after bootloader jumping to application. The limitation is that the former decryption using the symmetric key can only happen when bootloader code is still executing. It's not possible anymore after jumping to application. On L5, of course, the same secures and memory area and the protection mechanism can still apply on L5 to achieve the same thing. But in addition, trust zone feature can also be used to do the isolation by putting the key inside secure area and the application in non-secure area. The trust zone will bring more flexibility. On WB, there is the CKS custom breakage storage feature thanks to the service provided from the code running on M0 plus core and isolation mechanism between M0 plus and M4. The encryption key can be provisioned to the chip and be protected by CKS. Decryption using the same key can be invoked by both bootloader and application without exposing the key content. Anti-rollback is also an important aspect of the secure former update process. Former update shall check the former version and only allow newer version to be installed to the device. Former version info shall be part of the metadata provided along with former binary and need to be verified as well. Info of the version of active application former shall be kept on the device for anti-rollback check during the former update procedure. Integrity of the version info shall also be guaranteed. The new version former preparation flow. This is very similar to the flow that we explained in the bootloader section for the signing of the application binary. So again, you will need a public key pair and there will be a digest computation using the new version application former data and then the former digest and the other information of the former will be used to compute the digest as well as the signature data. And all the metadata including the signature will be combined with the new application. There is only one difference. In case former need to be encrypted then there will be also a symmetric key involved. And this key will be used to encrypt the former data and then the former to be downloaded is in encrypted format only. And then this public key of the key pair as well as the symmetric key will be embedded in the secure bootloader for the verification of the new version of the former to be installed. This flow chart gives an illustration of the basic flow of secure former update. So when the update starts the new version of the binary will be downloaded either from bootloader or from application. Then the metadata signature will be verified using the public key embedded in the chipset. If verification of first signature is okay then there will be a check of the version to make sure that we're not going back to an older version. If the version is also valid then the former will be decrypted in case it is in encrypted format. If not not the case then this step will be skipped. And then the former hash will be computed and compared with a value coming from the former metadata area. If the hash is also valid then we consider that this new version is authenticated. So this new version of the former will be installed and active application will be replaced by the new one. In this section we have addressed several main topics of secure former update. First, new former binary download capability through a communication channel. Second, insured authenticity of the new former to be installed by verifying the former metadata signature and the former hash. Third, ensure the confidentiality of the former during download by using a secure communication channel or by encrypting the former in the first place. And last, avoid former downgrade by checking the former version during the former verification procedure. Now you should have a complete view of security concept, STM32MCU security features and how those could be used to protect firmware. You have also the idea of what are secure boots and secure former update and their basic flows. So now we come to the end of this MOOC. Thank you for watching.