 Hello everyone and welcome to this presentation. Today I'll be doing the presentation with the help of my colleagues Sukanya and Ernor. First, let's start with the agenda. In the beginning I'm going to introduce the new SCM32-L4-S5 Discovery Kit IoT node. Then I will present the STSAFE A110. Next, I'll go through the device provisioning options with AWS IoT. After that, I will go through the details of XCube AWS 2.0.0. Before the hands-on session, I will go through the required tools and materials and go through the details of the scripts that we have prepared specifically for this seminar. We have planned three live hands-on. The first one is device registration and the use of the AWS Shadow Demo to connect to AWS IoT Core. The second one is we are going to demonstrate the multi-account registration option and then we'll finish with the OVDR update. And at the end, we'll finish with the conclusion. The new SCM32-L4-S5 Discovery Kit IoT node features the new SCM32-L4-S5 which is based on the ARM Cortex M4 with floating point unit running at 120 MHz. 2 megabytes of flash, 640 kilobytes of SRAM. The board also includes the STSAFE A110 secure element, a Wi-Fi module for wireless connectivity with cloud providers, a low-power RF communication with Bluetooth 4.1 and dynamic NFC tag, multiple sensors including accelerometer, gyroscope, magnetometer, humidity, temperature, MEMS microphones and proximity sensor. Also, the board includes an Arduino and a PMOD connectors to add extra features to the board. The STSAFE A110 is a highly secure solution that provides authentication and data management services. It can be integrated in IoT devices, smart home applications, smart city and industrial applications, consumer electronic devices. Its key features is authentications of peripheral secure channel establishment with remote hosts including transport layer security for TLS handshake, signature verification services, users monitoring with secure counters, pairing and secure channel with host application processor, wrapping and unwrapping of local remote host envelopes, on-ship key pair generation. Before your IoT device could connect and communicate with AWS IoT, you need to register with AWS. AWS offers multiple options to register your device. So you can use the Y-Clicks X5 Online Certificates. That's what requires you to create a certificate online and download it to your device. Also, you can use the Just-in-Time registration. So when your device first connects to the first time to connect to the AWS IoT, the server will detect unknown certificates and generate it by registering CA and will auto-register the device certificate. You can use the Just-in-Time provisioning, the device provisioning at the first connection. And to provision the device, you must enable automatic registration and associate a provisioning template with the CA certificate used to sign the device certificate. The new one is the Multi-account registration. So the Multi-account registration introduces an optional simplified registration step where customers can register their device certificate without requiring a certificate authority to be registered with AWS IoT. And customers also can move devices easily between their AWS accounts. So this enables the Multi-account registration. When you look at the different device registration options offered by Amazon AWS IoT, all of them require the following. So you need a secure facility to install the certificate and the private key, a trusted user and application to install the certificate and the key. The certificate key must be unique and the key must be unique. The required registered CA with AWS. A certificate and key could be compromised in some conditions and think can only be registered to one account except in the case of the Multi-account registrations. So what is the solution? The STSafe A110 comes with certificate and keys are pre-installed in ST's secure facility and factory. ST is the trusted user that installs the certificates and the keys. The certificates and keys are guaranteed to be unique per device. You don't need to register a CA with AWS. That's thanks to the Multi-account registration feature that is supported with STSafe A100. The certificate and key cannot be compromised. That's thanks to the security features of STSafe. Also you have the Multi-account registration. Also on top of that STSafe offers brand protection and more options. The XCube AWS is an SM32 cube expansion pack for AWS IoT Core. It provides a qualified port for Amazon FreeRTOS to the SM32 L4S5 Discovery Kit IoT Node board. It offloads the security critical operations to the onboard STSafe A110 during the secure boot and secure firmware update. The TLS device authentication with AWS IoT Core server. The verification of the over-the-air OTA update firmware image and integrity and authenticity. And also it leverage the secure element provided provision and certificates with AWS IoT Core Multi-account registration feature. The XCube AWS directory structure is as following. Here we have the drivers directory where we have the SM32 L4 drivers, the CIS driver and the BSP drivers of the components available on the board. In the middleware we have STS middleware drivers like USB library. In the third party we have AWS FreeRTOS that includes the RTOS itself, the MQTT library, PKCS level library and many more. The Embed Crypto and the Embed TLS is the cryptographic library used by SPSFU and the main application. Under the project directory we have the dedicated projects for the SM32 L4S5 Discovery Kit IoT Node. First we have the bootloader and STSafe that includes the key management service blob library, SPSFU which is the secure boot secure firmware update and it is the root of trust for the XCube AWS. The secure engine directory contains the secure engine source which is protected environment where all the critical data and operations can be managed in a secure way. STSafe provisioning used to customize STSafe A110. Under the cloud directory we have the AWS demos which is the project that trans Amazon FreeRTOS native demos and at the end we have the AWS test where you can run AWS test project. To understand how XCube AWS operates we first need to explain the memory partitioning. The flash in the SM32 L4 5S is split as following. First we have the SPSFU area where the SPSFU authenticates the application before running it and also authenticates and install new firmware and always runs first after reset. Also we have the download image area which is reserved for the OTA images received by the mail application. On top of it we have the download image header which is used by SPSFU to authenticate the new image before installing it. The active image hosts the main application which includes Amazon FreeRTOS, the MQTT libraries, the OTA agent and also communicate with AWS IoT Core. Also the active image has its own active image header that is used by SPSFU to authenticate the main application before running it. Also we have the swap area which is used by SPSFU during firmware update. The SE Corbin is a library that is part of SPSFU and is shared with the main application. It always runs under the firewall. Also it includes the Crap2 library, the key management service and communicate with SCSafe with a secure manner. Also the keys which are used to securely communicate with SCSafe are part of the SE Corbin and they are protected with the proprietary code protection option of SM32. XQube AWS uses multiple keys and certificate. So the first one is the device certificate which is part of SCSafe A100 is used to connect with AWS and it's unique per device. Also the device private key used to connect with AWS and it's unique per device. So the device certificate and the device private key, they are installed in ST's secure manufacturing facility and they are unique per device. And all SCSafe A110 are provided with a unique certificate and unique private key. The host MAC key and the host Cipher key that are present in SCSafe A100 and also in SPSFU. And they are used by the SE Corbin to securely communicate with SCSafe and encrypt the data exchange between SCSafe and the SPSFU and the main application. The root CA present in SCSafe, it can be the same for all devices and also the OEMs can provide their own root CA. We'll see the use of the root CA later during this presentation. Also we have the OEM certificate which is derived from the root CA. Then on the image header we have the OEM intermediate certificate which is derived from the OEM certificate and can be unique per division within the same OEM. And then we have the firmware signing and SPSFU signing certificate which is derived from the intermediate certificate which is unique per product. So these certificates are used by SPSFU. We'll see how SPSFU use these certificates. And then in the main application we have the OTA certificate which is used by the main application to authenticate any newly received OTA images. SCSafe A110 is delivered with just the device certificate and the device private key which are unique and they are used to connect with Amazon AWS IoT Core. So the SCSafe provisioning project is used to load the host MAC key, load the host Cypher key. So the host MAC key and the host Cypher key are used to securely communicate between the SCSafe and SM32 and encrypt the communication. Also load the root certificate, load the OEM certificate and then log SCSafe A110. So only a device with a host MAC key and the host Cypher key can communicate with SCSafe. So please note the default SCSafe provisioning project use the same host MAC keys and the host Cypher keys, the root and OEM certificates for all the devices. Customers must personalize it for their final product. SC Core Main is built as a library for the following reasons. First, it runs under SCSafe 32's firewall. Also it is shared between SPSFU and the main application. And also hosts the SCSafe bearing keys which are shared with SCSafe provisioning project. SPSFU is used to guarantee a unique entry point after reset and to ensure a mutable boot code. So it forms the root of trust for the application. Also it enforces hardware security mechanism and SM32 like readout protection level 2, write protection, PCWrap, MPU configuration, firewall configuration and enable the window watchdog. And also it enforces security check and performs firmer image verification before execution. Also updates the user application in a secure way to prevent unauthorized update. Please note the delivered SPSFU does not enforce any security so that the user can still plug in and debug the application. So security must be enabled in production context. You can refer to the XU AWS user manual for more details. After reset, SPSFU verifies the following. First it verifies the device protection features like the readout protection level 2, MPU configuration, the firewall configuration and any other security feature that is available on the microcontroller. Then it verifies the firmer signature and firmer signing certificate using the OEM intermediate certificate that are available in the active image header. And then it will you verifies the OEM intermediate certificate using the OEM cert that is available on STsafe. And then use the OEM certificate and verifies the OEM certificate using the root CA. And when everything checks, then you will use the firmer signing and firmer signing certificate to verify the active image header and the active image itself. And if everything is checked okay. And then the SPSFU will jump to the active image and run the main application. The active image receives a new firmer update using OTA from AWS Amazon AWS IoT Core. So at this stage the application image and header are seen as single encrypted blood from the main application. So the main active application verifies the received blob using the OTA cert and generate a reset to start SPSFU. So SPSFU received the received image using the certificate chain. And then SPSFU swaps the active image and the new image, including the header. So we'll do the swap while decrypting the new image during the process then generate a reset. And then after that the normal boot process takes place as we explained earlier. SPSFU includes a rollback mechanism in the case of the old image face to start or if the update was interrupted in the middle. In a way that guarantees that your application will always run even if the image receives a corrupted image or the update was interrupted for example during a power loss or a sudden reset. As we have seen there are multiple certificates and keys, libraries and projects used in XQBiWS and they must work together seamlessly. To do that we need to follow a strict order of project compilation. Building XQBiWS will follow this order. First build the two images SECorben. This will include the SD safe parent keys and generate a library called se underscore core dot pen. Then we build the two images SPSFU. This will include the SECorben and generate the final SPSFU image. After that we need to add the OTA certificate in the main application. Build the main application then generate the main application header and then combine the main application header and encrypt it and generate the dot SFB file. So generating the image header and combining the header and the main application is a script paste. After that we need to combine the SPSFU, the main application image and the main application header and generate a single dot pin file. Also this operation is script paste and it's handled automatically by the IDE. Now we have finished with the XQBiWS package presentation. Before we go to the hands-on session we need to go through the tools and the scripts that we have created specifically for this seminar. So the scripts can be found at the following link. Also we need to download the XQBiWS 2.0.0 from st.com forward slash XQBiWS. Also we need the SM32 cube IDE can be downloaded from st.com forward slash SM32 cube IDE. Also we need the SM32 cube programmer can be downloaded from st.com forward slash SM32 cube programmer. Also we need Python that can be downloaded from python.org. Here we use the latest because we tested our scripts with the latest Python. And also we need to install PySerial using the command pip install PySerial. Also we need the AWS command line interface that can be found at the following link. And also we need to download the OpenSSL that can be downloaded from the following link. Also we need to ensure that OpenSSL is added to the path used in the control panel. So we go to the control panel system, advanced system settings, environment variables and we add the path for the OpenSSL. Now I'm going to show you how to get the XQBiWS and also the scripts that we have developed specifically for this seminar. First open a web browser, go to www.st.com forward slash XQBiWS and then click get software. And here you will be able to get the software. I already have downloaded this previously so I'm not going to do it. After you download the XQBiWS 2.0 you need to extract it to C drive to get the scripts. So go to st.com forward slash defcon-mdg and click enter and this will download the zip file. So after the zip file is downloaded so double click on it to open it and then open the XQBiWS project and copy based in the XQBiWS 2.0.0. I already have done here so the file is already present here. So I will go ahead and open the directory and go through the details. So first here you will find the document, so here you will find this presentation. Shortcuts here so we have the shortcuts to the files that we are going to be using during the hands-on and we are changing them. So these shortcuts they are relative paths so it's very important to have the XQBiWS 2.0.0.0 extracted to C drive. And then here you will see there are multiple scripts so there are batch scripts and also Python based scripts. So there are three different types of batch file scripts. So there are one that starts with SCM32Q PROG. So these scripts use the SCM32Q programmer to update the firmware and reset the board using the SCM32Q programmer and the st-link. Also there are other scripts that start with AWS CLI so these scripts contain AWS CLI's commands. So I will go ahead and open one here in the editor. So these are the AWS specific commands to create a few things in AWS. Also here we have the third type of batch files so they start with the numbers 0, 1, 2, 3, 4 and 5. So these are the scripts that are going to be really used during the hands-on. So these scripts they make use of the other available scripts. So I will open the first one. So here these scripts relies on AWS CLI profiles so we will be using during the hands-on two different profiles. The first one is called PROD for production and the second one is called DEV for the development. So here we are going to create two different AWS profiles and we are going to be using them. So during the hands-on it's very important that you create a PROD account and a DEV account. If you create your accounts with different names then you will need to go to these script files and change your profile names here. And you will see here the batch file will make use of other batch files. Also the batch file will create other text files that can be used either for your own records so you will have traceability of what really happened, the ARN addresses and everything. And also these files are going to be used with other scripts to build the commands for AWS to create the certificates, to create the OTA job, the sending profile and the S3 bucket. The other file that is important is called keys.txt so if you go over there. So we will fill in our keys and secret keys and endpoints during the profiles creation in AWS. Now let's start with the hands-on. So the first hands-on is device registration. So the goal of the hands-on is to create two different accounts in AWS, DEV account and PROD account, build xcube AWS and use scripts to extract the thing name and the thing certificate from the STM32 and STSafe A110 and also create a thing in two AWS account, DEV account or PROD account with the same thing name and the same certificate using the multi-account registration. And then at the end we will show a demo on how to verify the connection to PROD account. So now I will let my colleague Arnold go through the live demo for the first hands-on. We'll need to make sure that the xcube AWS package is extracted to our C drive. So wherever you have it downloaded from the ST website, just right click on it, select 7zip and then extract files. In order to place it on our C drive, we'll click browse, this PC and then local this C and OK. So everything looks good here and we'll go ahead and start the extraction. Now when we open up our file explorer and navigate to our C drive, we'll see that there's a new file or a new folder called STM32CubeExpansion and so we can open that up to the side and what we'll need to do is place our DEVCON folder in that main directory. Now we can create our AWS IAM production and development user accounts. To do so, you'll have to log into your AWS console. I've already done so on Chrome and select IAM by typing IAM in the search bar on the landing page. In the left you can select users and then at the top add user. We already have an account called DEV so for example purposes we'll call this account that we're creating DEV1 and we'll check programmatic access as well as AWS management console access and then we'll auto generate a password and since this is an example we won't require a password reset. Under permissions we'll attach admin access and no tags are required for this demo so we'll just press next. Everything looks good here so we'll create the user. On this page there's a lot of important security credential information so first and foremost we'll have to download the .csv file and additionally we'll want to copy and paste some of these credentials into our keys.txt file within the DEVCON folder. So we'll open that up, push it to the side. So you have your two accounts that we'll be creating here. We'll copy the access key ID and paste as well as the secret access key and paste. And you'll want to keep your password in a safe location also. It's helpful to log into your second AWS account in a different browser. So on Edge I'm logged into our second account and I'll follow the same steps to create our production IAM user. Under IAM users, add user, prod. Since we already have a product account I'll call this one prod1. Check both boxes and uncheck require password reset. Grant administrator access, no tags, create user. Again we'll want to copy all the security information into our keys.txt file. So make sure to download the .csv file as well. To log into your newly created IAM user accounts you'll have to log out of the account you're currently logged into and select log back in. We'll do this for both our DEV and prod account. So I'll open Chrome as well. And we'll log into DEV. The passwords will be contained in those .csv files that we downloaded. But since I've created DEV1 and prod1 for example, I'll copy my passwords from the safe location that I've stored them in. One thing to make certain of is that your two accounts are logged into the same region. For the purpose of this demo we've used Ohio, US East 2. Now there's one more field that we'll need to fill in in our keys.txt file. And that's the endpoint. You can go ahead and search IOTCore in both accounts. And under settings you'll see the endpoint for both of your different accounts. So we'll copy those and paste them in our keys.txt file as well. Now that our keys.txt file is fully populated we'll make sure to save it. Next we can remove read-only attributes on some of the files in our execute AWS package. To do so we'll open up our devcon folder again. And underneath shortcuts we'll see a folder called demos. We'll open that and then the include folder. We'll right-click, scroll down to properties and then see how it says read-only here. We're going to uncheck that. Apply changes to folder in itself folders and select OK. Next we'll need to enable the shadow demo. To do so we'll go back to our stmcube expansion folder. And under devcon go to shortcuts. AWS demos config.h. And it will open up a folder, I mean it will open up a file in your default text editor. For me that's Visual Studios. In line 45 it should say config OTA update demo enabled. We're going to replace that with line 33. So config shadow demo enabled. Control C and then select and control V. File, save those changes. Now we can configure our AWS credentials. To do so we'll minimize this window. And back in our shortcuts directory we'll select AWS credentials.h. And for MQTT endpoint broker that's going to be the endpoint that we copied and pasted in our keys.txt file for dev. Our thing name is actually printed on a sticker on the back of our physical device. It should look similar to mine. Our Wi-Fi SSID is the SSID for your network. And your Wi-Fi password is the password for your network. Once we fill in all those fields we'll go ahead and press save. Just to clarify we've listed the dev account endpoint here. Because for the first part of this demo we'll be connecting to the dev account with our device. Later on we'll replace it with our prod endpoint which will allow us to connect to our prod account. Just a note before we continue. Ensure that the network you're connecting your device to is a 2.4G network. As this device is not capable of connecting to a 5G network. Also the most common security for home and business networks is WPA2. So unless you're sure that your security protocol is different don't worry about changing this field here. Now we can open Qbyte. So on our desktop select Qbyte and launch. So we'll want to import our project into our project explorer. So file, import. Under general we'll select existing projects into workspace. And next we'll browse for the folder. So on our C drive we'll select the SCMcube expansion project. And then projects, BL4S5I, applications, and then select folder. We will not be needing the test project today so we can unselect it and hit finish. Now as you can see we should have four projects imported into our workspace. These projects should be built in a specific order. The first project that should be built is SC Corbin. So we'll right click, scroll down to clean project, and then build project. Second project to build is SBSFU. Again right click, clean project, right click, build project. Next is ST safe provisioning, right click, clean project, and build project. And lastly is AWS demos, clean project. Next we'll configure our profiles in our AWS CLI. To do so we'll open command prompt, and type in AWS configure, two dashes, and then profile, and then the profile name. So for us we'll do dev first. Now the access key, if you remember, we pasted that into our keys.txt folder, our keys.txt file. The secret access key is here as well. Region is going to depend on your geographical location. For us it's US East 2, and then the output form is JSON. And we'll do the same for our prod account. And now both of our profiles are configured in AWS CLI. The command we can use to test our AWS CLI connection is AWS IoT describe endpoint, and then the profile. So we can verify here that these endpoint addresses are the same, and we'll do this for prod as well. And verify again that the endpoint addresses are the same. Now what we can do is run our first script. So in preparation for doing that we'll make sure our device is connected. And then we'll also open up our AWS console in IoT core for both prod and dev. And we'll navigate back to our devcon directory and double click zero create more. So basically what this script is doing is flashing our firmware. After it flashes our firmware it extracts a certificate for the device and the thing name. So here it's flashing the firmware. And now it's extracting the certificate there as well as the thing name. It will use that certificate and thing name to then connect to AWS and create a thing, a certificate, and a policy for the thing in both the prod and dev account. Now that the script is finished running it's just outputting what is going through the serial communication port. Then we can take a look in our dev and prod account refreshing. So if we go to manage and things we can see that we have two new devices created also certificates. We have a new device certificate created in both account that matches here. And if we go to activity in the dev account, if we go to activity in the dev account, we can see now that a shadow is being published to our AWS console and dev. But we are not having that shadow published here on our prod account. Also we can review the policies. So if we go to certificates, again that new certificate that was created. This is the policy that was created within our script. And as you can see here, the demo is running in the background on our device. We can also take a look at the files that were outputted by our script. If we check back into the devcon folder, you can see that there were two output files here. These basically give a verbose output for all the commands that were run for AWS CLI. As well as our policies for both accounts. You can open these and take a look at them as well. There was also a certificate for our device that was generated. A temporary text file, which doesn't contain too much important information. And then thing name dot text, which will contain the thing name of our device. Thank you Allure. And now we'll move to the second hands-on, which is the meta account registration. So for the goal of this hands-on is to demo the meta account registration. Where we are going to create a stunning certificate using OpenSSL. So this will be needed in reality for the third lab for the OTA. But we need to generate it in this lab and include it in the project. And then we are going to enable the OTA demo. Change the firmware to connect to the product account instead of the dev account. So the first one will be creating the signing certificate. So the signing certificate is used by the OTA agent to verify the new image. So this step is only needed in one time for a given program. You don't need to generate a certificate for every single device you have. So one certificate will be used across all the devices within the same project. After that, we'll need to open the generated certificate and copy it in the AWS underscore OTA underscore pal dot c. Enable the AWS OTA demo and the AWS demo config dot h. Set the endpoint address. So we change it from the dev account to the product account. Build AWS demo and then flash the demo. And after that, we are going to verify that the board is connected to the product account. Now I will let my colleagues Fukania to go through the hands-on. Now that we have the thing certificate and policy created in AWS, the next step to doing the OTA update is creating the code signing certificate. Now the script number one that you see over here does that. As a prerequisite open SSR should be installed before you click on the batch file number one. Open up cert underscore config dot txt in a text editor and change the email that is provided here to yours. Once this is done, let's double click on one underscore create certificate dot bad. Once this is done executing, let's make sure that everything was executed successfully. Now this batch file one underscore create certificate dot bad generates three output files. One underscore cert output dot txt and ecdsa signer dot cert and ecdsa signer dot key which will be used later. Now to make sure that everything went well on the AWS side, open up the AWS account with the prod login and click on certificate manager. Over here you will see that a certificate was just created. Now we need to configure the firmware for the OTA update. Go to the working directory and click on shortcuts. The four files that you see displayed over here are the ones that we will be changing throughout the process. Double click on each of these files to open them up in Q by the E as I have done already over here. Let's go to aws underscore client credential dot h file. The MQTT broker endpoint that is displayed over here is that of the Dell account. We need to change it to the MQTT broker endpoint associated with that of the prod account. To find the endpoint that is associated with the prod account, open up aws management console of the prod. Click on IoT Core and on the left hand side click on settings. The endpoint will be displayed over here. Let's copy the endpoint and paste it over here. The next is go back to the working directory and we need to open acdsa signer dot cert in a text editor as shown here. Now go back to Q by the E. Open aws underscore OTA pal dot C and replace PC client certificate PEM with the one that we just opened up right now. Make sure to do it in the manner that is displayed over here. Don't forget the new line character for the end of each line. Once this is done, let's open aws underscore demo config dot h and change config shadow demo enabled to config OTA update demo enabled. Right click on the project. Clean project. Now that it's done building, let's go back to the working directory and double click on stm32cubeprogrammer underscore update in order to flush the program that we just built to the board. Now, since we changed the MQTT broker endpoint from that of the dev account to the prod account, let's go into the prod account and make sure that the device is now connected in the prod account. So if you open up AWS management console of the prod account, click on IoT Core and on the left hand side under manage and things, click on the thing and under activity, you will be able to see activity that has just happened. Thus, the device is now connected to the prod account. Thank you, Sukanya. Now let's continue with our last hands-on, which is over there update. So the goal of this is to perform over there update. So to do that, we need to change the firmware version number, create a code signing profile, create an OTA role, create an S3 bucket and upload our new firmware to the S3 bucket and then create an OTA job and push the OTA. So what is OTA? OTA stands for over there update that allows you to deploy firmware updates to one or more devices in your fleet. FreeRTOS over there updates makes it possible for you to deploy new firmware images to a single device, a group of devices or the entire fleet. Deploy a firmware to devices as they are added to groups, reset or reprovision it. Also, verify the authenticity and the integrity of the new firmware after it's deployed to devices. Monitor the progress of a deployment and debug, fail it deployment. So the OTA activity flow is as following. First, in Kube IDE, we increase the firmware version, build the project and create a .sfb file. And then we need to upload that .sfb file to an S3 bucket in AWS. Then, sign the image and then create an OTA job. So once the OTA job is created, so the file, the new image is sent to your device. So the OTA agent that is running on your application will download the image stream. And then the OTA agent will verify the image signature versus the signing certificate that is embedded in the firmware. Store the firmware in sbsfu update slot in flash and set the image slot to new. And then we'll initiate a reset. So after reset, sbsfu will take control and will verify the new image and install the new image. And set the new image state to self-test. And then we'll call and run the new image in self-test mode. So if the self-test mode success, then the image will set its state to valid and report its states to AWS. In the case of the self-demo fails, so there are two cases here. The first one, for example, the application fails to connect to AWS. So the application will set its state to invalid. Issue a software reset. Sbsfu will detect that the image state is invalid and will revet the image to the older one and then run the old image. And then the old image will report its status to AWS. The second possibility that there was a hardware watchdog reset during the self-test, for example, the application fails to start. So sbsfu will detect that there was a watchdog reset, will set the image state to invalid, revert the image to the old one and then run the old image and the status will be reported to AWS. Now let's continue with the steps. So first thing we need to open the AWS application underscore version.h and change the application version major from 0 to 1. Then build the project. So to build the project, you can right click on the project name and then click the project. After that, we need to create a code signing profile in AWS. So this can be done using the batch file. Please note that this is needed only one time per project. So you don't need to do that for every single device. It's only one time per project. The next one is to create an OTA role. So creating OTA role on AWS, we can do that using the batch file. That's the same thing. So this step is only needed one time for a given program. Next, you can check the OTA role and the attached required policies in AWS console. After that, we need to create an S3 bucket and upload the newly created the firmware image, the dot SFB. This also can be done using the available script. So we can verify in AWS console that a new bucket has been created and also you can check the content of that bucket. And you will see that the dot SFB file has been uploaded to that bucket. Once that's done, so we need to create and push the OTA update. So this is also can be done using the batch file. So once the OTA job has been created, we'll see some activity on the console output of your board. And you will see that the board starts receiving the new firmware. Also, you can check the OTA update status on the AWS console by checking the job. And you can see here the status of the update. Now I will let my colleague Suganya go through the live demo. Now that this is done, let's go back to QBuyDE and go to aws.applicationversion.h and change the application version from 0 to 1. Remember that this step is very important. Now clean the project. Now that we have the code signing certificate created, the next step is creating the code signing profile. Bad script number 2 that you see over here does that. It uses search underscore config dot txt that was generated by the first batch file. Let's click on to underscore create signing profile. Once this is done, let's make sure the to underscore signer dot txt is generated and populated. Now to make sure that everything went well on the AWS side of things, let's go to the command prompt and first make sure that we're logged into the prod account over here by typing aws configure. Once we're sure that the access key ID that is displayed is the one that is associated with the prod account, let's move forward and type aws signer list signing profiles. You can now see here that this profile was created. Script number 3 creates an OTA role and attaches all the required policies which is the next step to doing the OTA update. It requires role policy dot JSON that is already provided here in the working directory. Let's double click on to underscore create OTA role. Once this is done executing, it will generate two output files, one of them three underscore role dot txt which is populated here and the other is stm32l4s5 underscore OTA policy dot JSON. Now to verify on the AWS side, let's go to the prod account and click on IAM. On the left hand side under access management, let's click on roles. Over here we can see that this is a role that we have just created with the attached policies. The next step to doing the OTA update is creating and versioning the S3 bucket. The bat script number 4 that you see here does that. It requires ting underscore name dot txt which was created by script number 0 as well as the SFB file location that is mentioned inside bat script number 4. Now let's double click on bat script number 4. Once this is done executing, it will produce for underscore bucket dot txt as an output. Let's double click to make sure that it's populated. To make sure that everything went well on the AWS side of things, go on to the AWS management console of the prod account, click on S3 and notice that this is the bucket that we have just created with the uploaded dot SFB file. The last and final step to doing the OTA update is creating a job and pushing the OTA. Bat script number 5 that you see here does that. It uses ting name underscore txt that was generated by running bat script number 0. It uses the bucket that was generated by running bat script number 4, the role from bat script number 3 and the certificate and signing profiles from bat scripts number 1 and 2 respectively. Now let's go ahead and double click on file underscore publish underscore OTA dot bat. Here we can see that the OTA update status stays as a job was created. Now you can see that there is a lot of activity that's going on on the terminal. The board is now receiving the new firmware. Let's go ahead and look. Before we look at the AWS console, we can see that a reset has been generated and SBSFU has started. SBSFU is now verifying the firmware image. Here we can see that the OTA demo version says 1.9.2. The version that we had flashed onto the board is 0. Thus, SBSFU has now installed the newer version of the firmware. Let's go ahead to the console. Make sure it's the proud account. Click on IoT Core. Go to manage and click on jobs. Let's click on the job that we just created and you can see that the status says succeeded. In addition, running bat script number 5 generates this particular text file as an output. In addition to this text file, OTA fields and OTA update.JSON. We thus have a successful OTA. Thank you, Sukanya. Now we can conclude our presentation. So during this presentation we introduced the XCube AWS 2.0.0 which provides a qualified port of Amazon Friartos. We bring a highly security thanks to SBSFU and STSafe A110 and we demonstrated easy of use thanks to Meteor Counter-Registration, STSafe A110 and the script-based provisioning and OTA updates. If you have any questions, so please don't hesitate to contact us using the online support, ST online support, and also you can post your questions to Amazon forum. Thank you and I hope that you liked this presentation. Good morning, afternoon or evening. It depends from where you are watching this webinar. First and foremost, I want to thank ST Microelectronics for this opportunity to participate this year at the first ever virtual ST Developer Conference. I have been to ST DevCon for the last three years. I love the community and I certainly looking forward to see you all next year in person. It's not secret that IoT is more than a buzzword nowadays. When I'm looking for the number of connection in my house at my 3-node mesh router, I'm often specialist and this is for the family of three. It is normal for my daughter to ask Alexa to spell a difficult word, close blind or change TV program. While I still reach out for dictionary and more often use remotes. So undoubtedly, the number of things going to be big. We don't know exact number, but we definitely know that IoT number is going to be much larger than the population of Earth. At AWS, we are blessed to collaborate with many incredible teams building myriad innovative solution. I had a privilege to work with iRobot at early days when they were migrating all the infrastructure to AWS IoT. And at that time, we had only very secure and scalable AWS IoT core message broker and identity service. We had very limited capabilities for the device management for entire analytic service. So pretty much everything has to be wired to this wide range of AWS building blocks. Well, ST was our strong partners even before AWS took our free RTOS project. Like for example, the first dash buttons, they had a STM32F205, if I am not mistaken, MCU. This year, I see a lot of customers that are building solutions with STM32MCUs. We see a lot of interest in the STM32H7F7L class series. And I cannot wait when the STM32WB and STM32WL will be included into XCube AWS to give developers this broader access to AWS IoT services from the BLE or ZigBee enabled products or from Lora products. Because STM32WL is the first combo MCU that has the Lora radio on a same chip. So what customers doing with AWS IoT? The companies like Fender, optimizing their manufacturing line. Philips, for example, they designed and deployed a system for remotely monitoring patients in a healthcare industry. And the companies like Visio, iDevices, iTron, building connected home and cities. Buyer, build a solution for growing healthcare crops with greater efficiencies. And the companies like Volkswagen, they optimizing all their manufacturing lines to be IoT connected to optimize all the processes to basically gain this efficiency. But nobody just buys the IoT technology for the sake of technology. Everyone seeks business outcomes. And typically customers looking to optimize these two categories. So it's either operational efficiency where we want to decrease operational expenses or in a revenue growth where the data driven IoT solution can provide a new services or even business models or to create a better relationship with your customers or optimize your product over the time. So what are the building blocks of AWS IoT? So we roughly can divide it into three categories. We have services and software for building edge devices. We have connectivity and control services. And finally, the services that allows companies to make sense of the data flowing from all of the devices. And all of those services are organically working together. And even with other AWS services like Redshift for data warehousing or DynamoDB, TimeStream as a database option or Lex, for example, to create intelligent chatbots. Let's briefly walk through all of the services that AWS IoT offers at the moment. We have software and the services to build and test connected devices. And we'll talk about some of those like Freer Toss and IoT Device Tester in more details later. Moving to the control services, the lower left corner. We have AWS IoT Core. The components of AWS IoT Core include an identity service providing authentication and authorization, a device gateway to securely connect devices to AWS cloud services, a message broker that processes and routes data messages to the cloud and between devices, a rules engine that triggers action on your devices. We actually recently got our 20th native rule integration. This time with AWS TimeStream database. It's a database that's specifically designed for time series data and optimized for IoT workloads. Device Shadow that enables application to interact with devices even when they are offline. For example, they are in a deep sleep mode. And a registry that enables automatic device registration and performs searches like which devices were made in 2016, for example. AWS IoT Device Management helps you to manage your fleet of devices. You can easily perform bulk registration of devices, fleet indexing and searches, device logging and monitoring, jobs like for example, or the air updates, secure tunneling which is primarily focused on the Linux, on embedded Linux devices at the moment. And finally, in this category, device defender service that helps you to monitor the device configuration and all the deviation from the norm. It also allows you to identify and mitigate the anomalies in the device traffic, like two devices connected with the same certificate or frequency of the messages increased. And going to the top category, we have AWS IoT SiteWise. It's a helpful tool to build dashboards and to bridge an industrial sensors like those connected through Modbus or OPC UA to the cloud. AWS IoT Analytics is a specialized data store for IoT data and allows you to build pipelines to enrich and combine data from different sources. AWS IoT Events can help to drive decision based on a very complex logic. The AWS IoT Events team recently open sourced their diagram maker, the tools to create, modify graph-like data and obviously visualize the graph-like data. And finally, AWS IoT ThinkGraph which is a bit of futuristic service that helps you visually via your IoT solution which is based on a device behavior. For example, the camera, the video camera can trigger the output, can get the input from who came through the front gate or the door and it can trigger an action, for example, to set up the comfortable room temperature or house temperature and for example, to turn on lighting if this is the night based on the preference of this particular person. I would like to keep as much time as possible for the awesome demo we prepared for you. So I cannot go into much details for each of those services but I would like to highlight some that will be important when you are designing and building connected devices. So how can you build devices at the age that work with AWS IoT? Typically, those devices based either on microcontrollers like STM32 Alpha Plus or STM32 H7 or microprocessors like, for example, STM32 MP1. Our preferred way for building MCU based solution is freeRTOS and using our connectivity security and management libraries and Greengrass for microprocessor-based designs. Typically, those running some sort of embedded Linux operating system. Why freeRTOS? FreeRTOS leads the MCU real-time operating system category. In a recent market study, freeRTOS was rated to be used in 28% of embedded project in the next 12 months with the next MCU OS coming at 9%. AWS continues to invest in freeRTOS since taking over the project while keeping it open source with even more permissive license, which is MIT open source license. We also recently announced support for two new architecture, RISC-5 and ARM V8M. And we welcome the upstream pull request for new architecture if you happen to port freeRTOS to the new architecture. FreeRTOS includes the freeRTOS kernel, the market-leading real-time operating system for microcontrollers. And we are very honored that Richard Barrie, who invented freeRTOS 15 years ago, had joined AWS as a senior principal engineer working on freeRTOS. It also has a number of local cloud connectivity libraries, also security libraries like TLS and PQC S11. And more AWS specific is a device defender library that resides on a microcontroller and enrich the metrics that device defender service sees at the cloud side. And finally, all their updates and code signing libraries that allows for securely update your connected devices in a field. So let's take a deeper look into each and every of these libraries or categories of libraries. Before I will continue, we right now have a very comprehensive documentation for all of the libraries we released at freeRTOS.org. And I urge you to take a look and give us the honest feedback. But you can find their comprehensive examples, also the architecture and the API description for each and every library. So the local connectivity from battery-powered devices is very important in our reference architecture. And it allows to keep those devices in a deep sleep mode for extended period of time. It's also important that these devices, when connected to local gateway, the local gateway can optimize and aggregate the payload from those devices and then send this optimized payload to the cloud. And it's important if your communication channel is expensive, for example, satellite or some expensive cellular connectivity. It's also interesting the approach that the team took when architecting the Billy Management Library. We implemented an obstruction layer for GAT and GAP. There was a debate if IP-based communication would be more preferable and kind of seamless. But since Billy supports cloud connectivity only through intermediate proxies, such as iOS or Android devices or Greengrass gateway, the GAP implementation is extremely elegant and also simple. We also provide the Wi-Fi credential provisioning over Billy in the designs where the Wi-Fi connectivity model and Billy model coexist on the device. The cloud connectivity allows to reuse the same MQTT libraries to connect to AWS IoT Core. We also now support HTTPS for cloud connectivity, primarily for over-the-air update, but you also, for example, can directly access any of AWS services through the RESTful API that is obviously based on an HTTP standard. And we have finally the JSON parser that allows you to interact very efficiently with the device shadows. As I mentioned before, shadows is a representation of the state of your device in the cloud. For the security, we have implementation of secure sockets using TLS, certificate-based mutual authentication, PKCS 11 subset of the standard for key management. And you will be working with, and you will see the demo later today, with STM32L plus board that has the STSafe A110 secure element pre-populated on it and pre-provisioned. And you will see how the secure element support implemented and how the PKCS 11 library is used. And obviously, because it's an open source, you can verify your code, but on our side, some of the portion of the code and we're striving to deliver all code is actually undergoing formal verification. Currently, for example, the TCP plus, FreeHertos plus TCP libraries undergoing through formal verification. Over there updates is extremely important because for the connected devices, if you don't have an ability to update the firmware on this device, it's becoming a doorstop in a year, right? So, our library implements two transport protocols. You can choose either to reuse the MQTT connection that you're already using as your controlling data connection, or you can opt for HTTPS if you have additional resources on your microcontroller and don't want to be metered on the number and the size of messages. Also, in July release of FreeHertos, we implemented and over there, library supports pose-resume OTA functionality. Edible SIT device defender, it's a library on the microcontroller, as well as the service at the cloud that allows you to audit monitor devices and also to identify anomalies in your traffic, right? And also react to those anomalies. To recap, FreeHertos provides you with trusted robust kernel, a royalty-free open source license, cloud agnostic libraries. You can use our implementation for MQTT or BLE with our cloud, and we would be happy, but you can use it with your on-premise broker if you want. Possibility for commercial support, comprehensive documentation for the kernel and all of the libraries on FreeHertos.org, libraries for transport security and key management based on open standards. And finally, over there, update mechanism using either MQTT or HTTPS. Now that we built our product, how can we be sure that our product would behave and feel the way it intended to do? Well, there are a lot of unknown factors we have no control for, like network outages, application code logic, environmental condition. We can perform a number of unit tests to verify that our libraries performs as they were designed. I mean, the FreeHertos libraries and connectivity libraries perform as they were designed. AWS provides device tests for FreeHertos and for AWS Greengrass. The product is locally installed on your computer. It connects to your MCU board through serial connection and to embedded Linux board through the SSH connection. And it compiles and performs a number of tests in case of FreeHertos and in case of the Greengrass, it brings the Greengrass binary and run a number of unit tests to test the functionality. For example, how the hardware security integration works with the TPM or how the stream manager works. Do I have MQTT connectivity to the cloud up to the standard? And so on, so on. You can also choose a pre-qualified platforms from AWS device catalog, such as, for example, STM32L+, or STM32H7, F7, the L475. One thing that I should really thank my ST colleagues is that they've been working very diligently to package the libraries and kernel into XCube AWS pack that allows you to consume all these libraries in a very natural way for the developers through the Cubemax and through STMCube IDE. So right now it's much, much simplified developer experience. And finally, while we just touch the very basic of AWS IoT services, I would like to show you the AWS investment to deliver the most comprehensive edge solution. So in addition to all IoT services, we're developing a product like Wavelength to deliver ultra-low latency application to 5G connected devices or the Snow family of products like with Snowball Edge and recently the very cute and small Snowcon and to the monsters like Snowmobile. AWS Outpost to bring basically AWS building block services to your data center or close to your customers and SageMaker Neo, for example, to optimize your ML models and do your inference from the edge devices. Thank you. And I'm passing a baton to my ST colleagues who prepare a fantastic demo for you that includes almost all of the concepts we just touched upon.