 In this part, I would like to give you a short introduction about security on MCU. Let's start with the definition of security, and you can find it in Wikipedia. Security is a degree of resistance to all protection from harm. It applies to any vulnerable and valuable assets such as a person, dwelling, community, nation, and organization. What is important in this definition is the fact it's a degree of resistance. It can be an absolute protection. Think about this. And then we've got this word asset. Let's try to define what is an asset. In fact, an asset is what you want to protect, but you want to protect it because it's valuable for you. But it could be whatever is valuable for you. So it could be an information. It could be a capability. It could be a feature. It could be a technical resources. In the case of the MCU, it could be some software resources, some access to the device, on such kind of things. So in fact, an asset is many things, and you have to identify this asset inside your product and the ecosystem associated to your product. In fact, to protect your asset, depending on this asset, you will protect different properties. We've got the CIA, the confidentiality, the integrity, and the availability. Confidentiality, that means the information is not made available to unauthorized individual entities and process. That means you ensure only people that have access to this asset or to the information how to get this access. Integrity, you ensure your asset has not been modified in any manner. Availability, ensure when you need information, this information is available. Leveraging ST's ecosystem to secure your STM32 application. In fact, today, IoT enables intelligent service everywhere. We live in a smart world with a smart home, smart city, smart industry, smart driving, and health. The backdrop of this huge interconnection level is that you've got some threat at each level. I mean, you can have threat at service and network level, at device level. You can have some theft of confidentiality or identity on the creation of counterfeit device or services. And to build a security, I propose to go through three main steps. The first one is threat analysis. That means on your system, you need to define or to analyze what are the assets, what you want to protect, what are the potential threats of vulnerabilities, and how you will find some contaminations. At a security, at a system level, sorry, you have also to ensure all the elements inside your network or system are well secure. And the last step is thinking about how I build a security from the G1 to the end of life of your product. First step, analyze your system. Let's start with some definition. First, the asset. The asset is what you want to protect. It could be your device, it could be your code, it could be your brand, it could be a location, whatever is valuable for you. Then the threat. The threat is what we need to protect against. In fact, the threat could damage your assets. Then the vulnerability. In fact, vulnerability is a weakness in your system. That means a threat could exploit a vulnerability to damage your assets. And finally, the risk. And the risk is the intersection between your asset, your threat, and your vulnerabilities. And building a strong security is to minimize this risk. So now we have the words. We've got the asset, what we want to protect, and we've got the threat that could exploit some vulnerability to damage your asset. And the intersection of all those are the risks. Let's define the process to do the threat analysis. First thing to do is to identify the assets in your system. That means what you want to protect. Then you need to identify the threat. That means whatever could threaten your system. It could be a remote attacker. We could imagine somebody would try to break into a room. I don't know, or someone would try to open your device. You have to think about all the control threats. Then you have to identify the vulnerabilities. I will just take the example with an IoT device with a hard node. I need to keep my debug port open for any reason. Is it a real weakness? An attacker could have a physical access to my device, connect with the debug link, and get some confidential information. This could be potentially one vulnerability. And the last point, maybe the more complicated one, we need to find some contaminations. We know that a threat could damage my asset thanks to its vulnerability. Which contaminations I could put into place to ensure my asset is preserved. Now, you should have in mind what is the threat analysis and how to do it. But keep in mind that during the lifecycle of your project, potentially we will discover new vulnerabilities, so you will have to do the reassess of all this process. Now, let's try to understand how we will build our secure solution from the design to the disposal. At the beginning of the product lifecycle, there is a definition of your product and also the design. At this step, you should do first the threat analysis. So now at the customer side, we need to identify the asset, the threat, and looking for vulnerability and contaminations. For the methodology, I already give you the input, but you can find more information on this link. If you find this too theoretical, I would recommend you to have a look in this example done by Harm for the PSA Threat Model Analysis. There is three IoT systems who are fully analyzed and you can just have a look in this documentation. Quite easy to understand and it really shows you how to do this concretely. Next step is the design and the development of your product. And here again, we will try to identify how to to determine properly to mitigate any threat. Now, the project team should find the hardware solution or software library to help him building a secure solution. In fact, ST has a wide product portfolio and strong security ecosystem. Depending on the selective device, we've got different mechanisms like secure boot, debug lock, MPU, some isolation with firewall, threat zone, dual core, and also the capability to interface with a secure element ST safe. This is for the hardware resources. We also provide you some software resources with some X-Cube CryptoLib, the SBSF, for example, the PSA-TFM on the Hellfire Specific, some fast rom or programation services, and secure firmware install. You can find many details about this in our site in the STM32 Trust. And also you can have a look in our security MOOC, which are also available on our site. So building the security with STM32 could be combined with the ST safe. STM32 brings many mechanisms like memory protection, readout protection, write protection, put some portion in flashing execute only with PCrop, some hardware accelerator for the crypto, and some isolation mechanism like memory health protect, threat zone, and such on. We also provide you some software packages with the CryptoLib, the SFE, and the SBSFU. But the STM32 MCU is a general purpose device. That means if you got a cynical attack, someone tried to delaying something or you won't resist frankly speaking. If you need to resist such kind of attack, you can have the ST safe, which is a secure element. And this one guarantees an optimum security against silicone level attacks and board attacks also. So there is some specific congealment and there is some strong authentication. There is the capability of key storage, of code storage, and also there is some mechanism of key provisioning. So I would say adding a ST safe, you have a higher level of security if you need it. Now how to address the security during the manufacturing. In fact, the device owner often use a contract manufacturer to program the device. But in the same time, you want to protect its code from linking, and you also want to prevent some over production. To avoid any linking of your code, a mechanism would be to encrypt your firmware and ensure that it was decrypted inside the MCU at the first flash. For the over production, you should find a way to count the produced pieces in a trusted way. With an SSM for example. In fact, we proposed some solution for this. So it was a secure firmware installed mechanism. You can see here the different documentation and also you can go home. Our site will have details about this mechanism and how it preserves the confidentiality of the code and also to prevent the over production. And the last step of the product lifecycle is in the field and the hand of life. In this context, the device owner want to ensure about the authenticity of the firmware that is running on the device. And also we want to have the capability to communicate with it in a secure way and also to do some secure update if needed. To address this problematic, in fact, we need to implement a route of trust in your application to communicate of a secure and trusted channel and have some check firmware update authenticity and integrity. If you are a little bit familiar with security, it's what we often call a secure boot on a secure firmware update. We also propose some packages to address this problematic. The SBSFU with secure boot and secure firmware update packages. And on the hell far you've got the TFM, Trusted Firmware Quarkotics M, which rely on the HAM PSE initiative. Another point is to ensure that we have secure all the elements of the system of the network. To ensure your security in a global system, you have to ensure that there is security at each level. First in the IoT Server security. Okay, it's a little bit out of scope regarding MCU, but it's something that you have to take into account in your security analysis. Then at the gateway level, here you can use the MCU G4, HALF4, HALF5, F4F7, H7, MP1, one more, depending on your needs. For the security aspect, we still have those packages with secure boot, secure firmware update and the TFM on the HALF5. And finally that's on the node where the price and city of the device is important. Here we've got some G0, G4, HALF4, HALF5, WB and more. I'll let you have a look in our proposal. And we can also address the security stuff thanks to our software packages and the security IP embedded in the different MCU. And now to conclude this presentation. So now you should have in mind that security should be seen from the G1 of your project until the end of life of your product. The first step of your security definition should be the security analysis of your system. And I remind you of all the system, all the content part from the cloud until the getaway, until the on node. You have to identify the assets, the threat and the vulnerabilities. Thanks to this information, you can think about counter measurement and the strategy to address a good level of security. Then you can rely on ST security ecosystem. We've got all our MCU with different security mechanism and also the security packages that is delivered for you. Those one have been certified and guarantee a certain level of security. And if you need to be resistant to any advance attack at board or silicon level, adding a ST safe companionship to the MCU will address this requirement. The STM32 trust ecosystem combine knowledge, design tool and ready to use original ST software. This allow you to build a strong security into your product device. All the related resources are now in one place www.st.com. I hope you enjoy this presentation and thanks for your attention.