 Hi everyone, thanks for coming to this presentation at Embedded World. I'm delighted to be with all of you this morning. We're here to speak about security. The point is, security is at the core of any connected device. How can we address security? How can we do it the right way? That's the point. Just like any silicon vendor, we have some ideas about the way to do this. We have some ideas coming from our legacy business in SmartCard that we call now SecureElement. But how to address it properly for IoT business knowing that the constraints are different. We have a huge panel of customers. If you discuss with any silicon vendor, they will tell that we don't know all our customers. We have tens of thousands of customers doing multiple applications, different segments, we call it general purpose business. But it can be around automotive, it can be around consumer, it can be around industrial and so on. So compared to the original security business that was pushed by the SecureElement business around payment cards, ID and so on, this is something really different. So how to solve this conundrum? That's why we come with a solution which is based on silicon because this is our DNA. We speak about silicon devices and we address this need, this requirement because we know that regulation is coming. Today we see the increasing number of devices. With the rising number of devices connected to some back-end services, cloud services, whether from the GAFA or even private cloud as well. How to address this security conundrum? That's the point of my presentation. And we think that the appropriate answer est to go through a silicon route of trust. C'est what I'm going to introduce here. So I will say a brief word about STMicro and STM32. This is at some point a commercial presentation but I will go fast on this aspect just to stress the importance of the security route of trust. That is very important. And how do I address this? And what is enabled in the end? Because having a route of trust is one thing. Ok, we answer the question of security but can it be as well an enabler to additional security things including services, provisioning, all that stuff that's coming on the top of the original silicon device. So about ST, ST is one of the largest microcontroller vendors. Last year it was pretty good. We reached up to 60 billion dollars of revenue. So the business is booming. We are happy about this. We have around 1,400,000 employees around the world. We address multiple markets with multiple manufacturing sites. ST is back at some point back to the original IGM model with increasing the capacity of manufacturing in Europe and all around the world. That is something quite strategic these days. And we are focused on CSR constraints meeting some global standards. Regarding the product, just like you have seen in the previous presentation we address multiple markets. This one is the original world map and product portfolio I would say at some point. So here you will have some low end products with addressing ultra low power, addressing mainstream MPUs with low end, high end and mid end as well. We have as well some wireless MCUs addressing Bluetooth, ZigBee and all the classic wireless protocol. And what is interesting here is that for any new product we place on the market we target two silicon security standards which is PSA certified. It was promoted and pushed by harm a couple of years ago. Now it's in place. And next to that we have CZIP which is discover more or less the same thing. It brings more flexibility. And CZIP is promoted by a consortium of industrial companies with the focus of having something robust in term of silicon covering some security function. I will go through this in a couple of minutes. So this is the right product portfolio covering all the different segments you can find where you can find MCUs in fact. So regarding IoT security that is something that is important and that we need to address. One thing which is of importance at ST on a yearly base we ask customers to come at a special event we ask them about the expectation in terms of performance in terms of features and in terms of security. All of them want to introduce some sort of security in their product but they don't really know why. How? Sorry. They don't have the expertise. Security is quite complex. It has an impact on performance. It has an impact on the lifecycle. So it's quite complex to integrate. So at some point companies like 60 have to come with an answer. Beyond this, beyond the technical aspect there's the issue of regulation. I would say that today there's been some progress but regarding security, evaluation and certification the ecosystem is still much fragmented. So why should I cover one specific security standard? Why there are other standards? In the end, how can I put my product on multiple markets with one security certification framework? Today that's the real issue. It is driven by private sector and public regulation. So it's not aligned as of today. We need some global recognition because today products are global. They need to address all the markets and all the places around the world. So how to address everything? Every place is in one shot. And beyond this, there's a question of national sovereignty, governments and nation for their national agency. They want some sort of security standard. They have some expectations. So how to address this? How to tackle this? This is not simple. But we think that let's go to the bottom to the root of the problem. We think that we can do this thanks to a foundational approach with a minimum set of security function and a sort of strategy with one thing that we call scale up. What I do on one product, I can do this on multiple product. What I do on one MCU for my product portfolio, I will have the same approach for the other MCU covering different business with more performance and so on. So having one unified approach in order to scale up. During some reuse, this term comes from the original smart card business. When you certify the silicon device, you have the possibility to do the certification of the operating system without reevaluating the silicon device. So that's what we call reuse and the right word is composition. And the last thing is about mapping starting from the security function that are covered by the silicon device. Some of them can be reused to cover the security function of the OEM device. Meaning that there are some synergies between what can be done at the silicon device and what can be done at the OEM device level. That is very important. So we have some sort of scaling here thanks to what we can do around the silicon route of trust. So what we propose at ST we propose a sort of framework. I will say it's a high level framework that covers some classic security function. I think about the secure boot, the secure update, the secure storage. So in any device we have some cryptography function but cryptography in itself is fine. We have established and proven algorithm for many years but the key issue is how do we protect keys. That is the key problem today around cryptography. So what we need to implement is sort of secure storage to protect keys properly thanks to security measures, thanks to specific APIs. Then we have additional security function including device authentication. When I connect a device to the cloud, to the internet, how can I prove that it is a genuine device? How can the vendor on the cloud side can be sure that it is not a fake device? That is something really important. Next to that we have what we call about software IP protection. We go back to this sort of thing. It's about protecting customer firmware but protecting as well some third-party components that may come from additional vendors focusing on AI or other very specific functions. Then beyond this you have secure manufacturing application lifecycle. We speak about commissioning the device bringing some certificate, bringing some credential and then how to decommission the device when it reaches the end of life. All of this is quite important. At ST we have defined some sort of meta framework covering all these functions just to explain how to focus on what is really important in terms of security for connected devices. It's a sort of streamlined security framework. The goal is to protect customer access during product lifetime. We cover this thanks to a set of security functions that you find here on this circle. And how can we prove that these security functions are properly covered? This is done thanks to security violations thanks to security assurance. Starting from the STM32 trust framework we are boiling down to two security certification programs which are very important today for silicon devices and that have the value of existing and at ST this is a strong strategy around security. The beauty of this is that we do one single evaluation with certified and accredited laboratories and in one evaluation we can cover the two standards. First of them is PSA certified. A couple of years ago, ARM introduced the platform security architecture for connected devices. It is based on the ARM architecture but at that time there was nothing. So they brought their technology, some specification, they brought the architecture of the route of trust and thanks to that you have the possibility to develop an application in a secure way on top of this PSA architecture. The second one is CZIP. CZIP stands for Security Violation Standard for IoT Platform. This standard was initiated by one silicon vendor. One silicon vendor a couple of years ago. It is now accepted by the whole industry and compared to ARM PSA it has more flexibility. That means that thanks to CZIP we can cover entry-level devices that don't feature physical isolation through the ARM trust zone. That's interesting, that means that even with entry-level cores just like some RIS-5 or Cortex-M0, Cortex-M5 we can claim a strong level a high level of robustness for silicon devices. What's behind this, in fact it's quite complex but what's behind this is a set of security functions. I would say that is the baseline for IoT Platform Security Certification. We speak about identification, identification of the device. We speak about secure communication. How do we guarantee that the device communicates securely with another device on the PCB in the application. It can be connecting with a radio device connecting with a sensor. And how do we guarantee that the product life cycle is protected that we cover all these devices all these states properly without any security breach. We speak about factory reset of the platform secure install of applications secure install of the route of trust this sort of thing. The beauty of this is thanks to this security evaluation and certificate application program. You don't have to take care of this. This is taken in charge by ST thanks to our team of engineers they develop the silicon device plus the embedded software that meets this security function. This is the first set of security functions. We have another one that is of interest as well. We speak about this list comes from CESIVE in fact. We speak about the robustness of the device on the target of evaluation depending on the security level that is expected. We can define the risk we can define the type of attack that may be under analysis. Depending on the risk we can limit to software attacks meaning the device is considered as safe and all the attacks will come from attackers connecting through communication channels, through USB, through user, through SPI, any kind or even radio. We have this model but beyond this now we consider physical attack and we have put in place some security measures to bring some physical attack resistance this is more or less what has been introduced in smart card 20 years ago and we consider that today it is important to have some robustness against what we call side channel analysis meaning people trying to monitor inside the chip thanks to the electromagnetic emission or the power consumption by putting a small resistor on the power supply. So today we claim this sort of feature as well because we consider that 4 products that will be on the market for let's say 10, 50 or 20 years we have to take this risk into account right now. Beyond this we speak about additional function about compliance with additional standards and so on and all the things that manage VSTs so as an application vendor they need to focus on this because it's already managed by the silicon vendor. So if we now read down to the root of trust there are 3 key messages here First we can deliver a robust and proven root of trust which is a cornerstone of an IoT device thanks to this standardized certification evaluation and certification approach with PSA certified angle battle form CZIP thanks to a list of security functions that are briefly described on the previous slide so this is the first point. The second point is this root of trust that has been tested is the entry point to additional security certification at the device level there are still much fragmentation here but thanks to this root of trust we think that depending on the segment dispending on the evolution of the regulatory environment we can cover many of them we speak about some private schemes here we speak about UL2900 on the right you have CSA, MATER CETA develop its own security certification framework for radio devices we speak about EN33645 for METC which is quite popular now between CZIP and the ATC to do some mapping how do you do a sort of equivalence between the value scheme in order to speed up the certification of the UM device for industrial application people work on a mapping with IE62443 which is very important as well and beyond this in the US IUXT and what is very important on the last part of the slide is the European and US IOT regulations that is coming you may have heard about Radio Equipment Directive Red you may have heard about Cyber Security Residence Act it's coming today it's not in place but if we think about applications that will be on the market in 4 or 5 or 10 years from now we need to take all this into account so this is the second point and the third point because here I spoke much about constraints we have to integrate security we need a robust route of trust we need to be compliant with some standard but beyond this what we need to think is that there can be value beyond being protected there can be value because we consider that having a robust route of trust can be an enabler for additional security services some are legacy services I speak about secure boot and secure firmware update which is something commonplace today for any IOT device we can deliver services around secure storage device attestation and what is pushed by ST and I invite you to come on our booth because we are up to 5 demos around this new service we think about introducing some third party software meaning that one vendor can develop its own software and then license some additional software coming from AI vendors coming from people expert in motor control they have the possibility to license this software have it integrated in their application without attacking at some point without having access to this third party component meaning that we can deliver some sort of business model around this and that is the beauty of the things we can have multiple vendors having different software and every part is protected from the others so there is no issue with security no issue with copyright and this can be done thanks to this new type of services so that is the beauty that is interesting thing that is brought by this new service I will go back to it later on so I spoke about security thanks to PSA certify and CZIP SST we have a strategy is that for any new device we place on the market we consider that it has to meet level 3 which is today quite demanding for the IoT market so we claim CZIP level 3 and PSA certify is level 3 including physical attack resistance that is something important because we will cover side channel resistance for any new device here we have 3 different class of product on the left part that what we consider legacy product even if today we saw lead by millions but from the security standpoint we call them legacy but it's not legacy at all at some point we claim level 1 meaning a sort of security level which is declaration about the security function that have been implemented in the product there's no pentesting, no code review so that's the entry level it's aligned with PSA level 1 and CZIP level 1 at some point even if CZIP level 1 is a bit different so in this category we define some existing STU product we speak about high performance STM42H7 G0, G4 for mixing all application this one is in place next group next category is level 3 with open source software the first of them that was introduced quite 2 years ago is STM42U5 it's an entry level product with ultra low power performance back resistance and physical isolation in this profile we have a robust route of trust with open source software here it revolves around ARM TFM that is an interesting component because it delivers services TFM support Secure storage crypto attestation you have all these services that comes on top of the silicon device and UNST for this evaluation and certification of the device in the scope of evaluation you have the silicon device plus the ARM TFM so here U5E35 MPE135 fall into this category as well this one is CZIP level 3 there's no TFM because it's an MPU and then we have WBA then we come to the third category which is STM42H5 in this category even if TFM is supported we introduce what we call the secure manager that covers the same specification as ARM PSA TFM but beyond this we introduce what I just mentioned which is the secure manager with the possibility to have some third party software component directly supported by the route of trust so this is a comprehensive solution that is developed, supported and maintained by ST so it's a sort of one stop shop solution any developer can take the device plus the software and have something robust and we just focusing on the application that is on the non secure part querying services to the secure manager that is PSA compliant in term of API so once again what are the key takeaways here they are free of them once again the route of trust is at the heart of OM IoT device security so 3 important things 1st of all is having robust and proven meaning certified route of trust gives evidences and build trust to the final customer to go through this we are going to introduce a program with logos with white paper all that stuff just to explain that what is considered as robust and has been tested by an independent laboratory it covers the silicon device some embedded secure software in line with a set of security function I spoke about secure boot, secure firmware update all the security function that are necessary to a secure IoT device the 2nd one is a way to is a path to security certification as we have developed I spoke about 62443 I spoke about all the security standard that are now many on the market that can be addressed easily and accelerated thanks to the security route of trust and the first point is opening the door to third parties and additional services it can come from additional vendors here on this part we work with Amazon, with Microsoft with Kudalski if you come to our booth you can see all the demos we offer cloud connectivity thanks to a specific additional application in the secure area they takes in charge management of the credential independently for the OEM application so we have a clear segregation here between the serious component and we guarantee the security of each subcomponent so that was really interesting here and I invite you to come we have a follow up discussion if you have some question and if you want to go further around these reports if basically you have an interest in this so thank you very much if you have some question just let me know I still have 2 minutes left for this thank you