 Hi everybody, welcome to Securing Connected Devices, and we're going to do that using STM32 Trust Security Ecosystem. So my name's Greg Perl, and I'm the STM32 Product Marketing Engineer for Security and our industrial market for microcontrollers and microprocessors. So let's start with an overview of the STM32 Trust Security Ecosystem and what it has to offer. The STM32 Trust offers a robust multi-level strategy to enhance security in your new product designs. Using our STM32 microcontrollers and the STSafe secure elements, it is our security framework combining our knowledge, ecosystem, and security services, offering a complete toolset for code and execution protection. It ensures IP protection, data security, and validated credentials are used and helps to guarantee firmware authenticity and secure firmware updates. And finally, the STM32 Trust brings 12 security functions which align with customer use cases and security standards. So let's take some time and review six of the most common use cases and how the STM32 Trust can address these common use cases. In our first example, we focus on secure manufacturing. Bob is CEO of a company designing toys. He'd like to make sure the firmware developed by his team is protected from theft and will only run on the hardware developed by his team. To achieve this, Bob needs to ensure the manufacturing of his toys by securing the first installation of his firmware in an untrusted environment. He also needs to protect and update his firmware in the field. And finally, he needs to detect and log possible attacks on his toys. In our second example, we look at IP protection and isolation. John is at the head of a company selling firmware and receives royalty payments from his customers. The firmware developed by his team is very valuable and it features application options that can further be enabled by the user. To secure his business, John needs to isolate and protect his firmware. He needs to ensure he can securely update it independently. And finally, he needs to set unchangeable application states to protect the enabled options. The third example looks at a secure boot and secure firmware update. Mark sells, excuse me, costly equipment and wants to offer a firmware update service. He wants his service to only update his equipment and would like to make sure only his firmware runs on his devices. To achieve this, Mark needs to implement a secure boot to check the authenticity of the firmware running on his devices. He also needs to implement a secure firmware update to check the integrity and authenticity of new software released before installation. Finally, he needs to identify and authenticate his equipment when deployed to the field. Secure communication is our fourth example. Oliver is selling devices that report sensitive data to a central server. He needs to make sure the data is protected and can't be exposed to people outside of his company. He also needs to authenticate devices and enable secure end-to-end data communication between his devices and the central server. He also needs to encrypt all the communication without exposing the encryption key to guarantee the integrity and confidentiality of the data exchanged. Brand protection and product identification is our fifth example. Rose controls her fleet of devices from a remote server. She wants to be sure no counterfeiting or malicious devices are running with her server and would like to have full control over these devices. Rose needs to protect her devices by checking their genuineness with a unique identity personalized during manufacturing. She also needs to check the access rights of the remote server operating the devices. And last, she needs to secure the data communication between her devices and the remote server. Finally, data protection is our sixth example. Jack is collecting user data within his devices as part of a larger system. His devices and system needs to be in line with regulations to be able to promote and sell devices. He needs to ensure the confidentiality of the user data which is collected and stored. He also needs a secure boot ensuring platform integrity which collects and stores his data. This ensures that malware won't read and expose the stored data. So let's take a quick poll. Which of the use cases presented was most related to your current design? Secure manufacturing, firmware isolation and IP protection, secure boot and secure firmware update, secured communications, brand protection and identification, data protection, or none of the above was particularly useful to me. So again, which of the use cases was most related to your current design? OK, great. So based on these common use cases, we've defined a list of security functions which we have mapped across our product portfolio. The STM32 trust brings 12 security functions to align with customer use cases and security standards. The STM32 trust brings the documentation software tools to cover all of these 12 security functions, abnormal situations handling, secure boot and secure install update, isolation, secure storage, crypto engine, silicon device lifecycle, application lifecycle, software IP protection, secure manufacturing, audit logs, identification, authentication, and attestation. Our STM32 trust security framework consists of our STM32 product portfolio combined with our SD safe product portfolio. And one can see how it can align to security levels defined in standards such as shown here, IEC 62443. For a security level one, the firmware running on our STM32 products can provide software countermeasures to make casual hacking difficult. This firmware can utilize a crypto engine which can speed up the processing time that crypto algorithms require. For a security level two, our STM32 portfolio can add hardware countermeasures against remote software and board level attacks, use trusted execution environments, one time programmable services, key management services, and implement static firewalls or dynamic firewalls such as the trust zone in our new STM32 L5 or STM32 MP1. Adding the SD safe can provide a hardware tamper proof system. This acts as a local host security module that is certified to common criteria levels higher than our competition. These common criteria levels ensure a secure device from product development, fabrication, provisioning, and personalization to secure the complete supply chain. So let's take a look at ST security evaluations and certifications that we're running to assess the robustness of our solutions. You can reuse our evaluation results as a template to compose security evaluations of your own products. We address IEC 62443 compliance with our STM32 trust ecosystem, typically used for system security evaluations. And as with most security evaluations, there's no component level secure certification. But our security functions can help implement layers of security. These systems require to achieve the different security levels one through four. This table summarizes all the evaluations and certifications we have so far. For ARM PSA, we have the STM32 L4 and the STM32 L5 certified PSA security level one. And the STM32 L5 with TFM certified PSA security level two and compliant to the PSA functional API. For CSIP, the STM32 L4 with XCube SPSFU is certified CSIP level one and level three. On top of the ARM PSA and CSIP certifications, we also have the STSafe secure elements, which are common criteria certified at a banking level for state of the art security. Finally, we have system-on-chip solutions based on the STM32 L4, which is compliant to PCI standards. ST will continue to evolve and lead in this area with our new products being tested and certified. So now let's take a quick poll, again, about security certifications. So which security certifications are the most important to your company? IEC 62443, CSIP levels one and two, CSIP levels three or four, ARM PSA levels one or two, ARM PSA levels three or more, the common criteria, PCI, EMVCO, FIPS, or some other one I haven't mentioned, or I have no idea. So again, which security certifications are the most important to your company? So what are some of the key points to remember? First, the STM32 trust security ecosystem is a unique and certified security framework, helping to implement security in new product designs. Starting from a common security needs, we've defined a set of 12 core security functions implemented across our STM32 and STSafe product portfolios. For seamless implementation of a secure boot and secure firmware update, or for secure manufacturing of devices with strong certification according to new security standards, our STM32 trust ecosystem is the first on the market certified PSA level two and CSIP level three and can participate in larger systems such as PCI, FIPS, and IEC 62443. So in the end, our customers can really trust what ST can deliver.