This page gives information on the Proof Of Concepts (PoCs) based on Trusted Firwamre-M (TF-M). It demonstrates Non-Secure Applications availing Secure Services in Trusted Firmware. The PoC have been demostrated at various events such as ELC at Edinburgh, Linaro Connect at Vancouver. **1. Pelion Client using TF-M **The PoC is done on a [[ https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board | MuscaA board]]. One of the Cortex-M33 processor on the MuscaA board runs Trusted Firmware-M on the Secure domain and Pelion client on the Non-Secure domain. mbedOS is the RTOS running on the Non-Secure domain. The PSK credentials are stored in the Secure domain using the TF-M Secure Storage (SST) service. Pelion client fetches these credentials for establishing secure connection to Pelion portal. Resources (e.g. LED) on board can be accessed using the get/put/post methods over the internet through the Mbed cloud portal, the duration can be changed through pattern resource. Here is a functional block diagram showing the components involved in the PoC. {F8372} Using Secure Storage Service 1.Mbed cloud app fetches PSK from Secure Storage in TFM 2.Keys are used to secure the communication between client and Pelion portal 3.App uses the IP stack (TCP) for communicating with the internet 4.Connection is established between the client and Pelion portal. Client is registered with the portal {F8374} Using Secure LED Service 1.Remote server initiates get/put/post commands for resources over internet 2.Pelion client receives these commands 3.Mbed cloud app uses secure LED service to blink the LED in a predetermined pattern. {F8376} **2. Google IoT Client using TF-M **The PoC is done on a [[ https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board | MuscaA board]]. One of the Cortex-M33 processor on the MuscaA board runs Trusted Firmware-M on the Secure domain and Google IoT client on the Non-Secure domain. Zephyr is the RTOS running on the Non-Secure domain. The client requires signed JWT (JSON Web Tokens) to perform handshake with Google MQTT server. The Client running on the Non-Secure side uses JWT sign service in TF-M for signing the token securely. A blink LED secure service in TF-M is invoked whenever the client talks to the service. Steps: 1. After secure boot, Trusted Firmware runs in Secure space and jumps to Zephyr. 2. Zephyr start in Non-Secure. Connect to google server by TCP with TLS handshake 3. Call secure service from Zephyr to TFM for JWT sign 4. Connect to MQTT server and subscribe the device config topic 5. Get the latest configuration from server and publish device status periodically 6. Blink LED by calling secure service when talking with server {F8383}

This page gives information on the Proof Of Concepts (PoCs) based on Trusted Firwamre-M (TF-M). It demonstrates Non-Secure Applications availing Secure Services in Trusted Firmware. The PoC have been demostrated at various events such as ELC at Edinburgh, Linaro Connect at Vancouver. **1. Pelion Client using TF-M **The PoC is done on a [[ https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board | MuscaA board]]. One of the Cortex-M33 processor on the MuscaA board runs Trusted Firmware-M on the Secure domain and Pelion client on the Non-Secure domain. mbedOS is the RTOS running on the Non-Secure domain. The PSK credentials are stored in the Secure domain using the TF-M Secure Storage (SST) service. Pelion client fetches these credentials for establishing secure connection to Pelion portal. Resources (e.g. LED) on board can be accessed using the get/put/post methods over the internet through the Mbed cloud portal, the duration can be changed through pattern resource. Here is a functional block diagram showing the components involved in the PoC. {F8372} Using Secure Storage Service 1.Mbed cloud app fetches PSK from Secure Storage in TFM 2.Keys are used to secure the communication between client and Pelion portal 3.App uses the IP stack (TCP) for communicating with the internet 4.Connection is established between the client and Pelion portal. Client is registered with the portal {F8374} Using Secure LED Service 1.Remote server initiates get/put/post commands for resources over internet 2.Pelion client receives these commands 3.Mbed cloud app uses secure LED service to blink the LED in a predetermined pattern. {F8376} This Proof Of Concept was shown as a Demonstration at ELC-E in Edinburgh in October 2018. The sensor on the MuscaA board was used to detect the motion of a Robot. The motion information was sent to Pelion Cloud using the Secure connection established as described above The Pelion Cloud displays the motion information on a graph as shown in this video [[https://www.youtube.com/watch?v=g1dmE1U3dls&feature=youtu.be | Demo]] **2. Google IoT Client using TF-M **The PoC is done on a [[ https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board | MuscaA board]]. One of the Cortex-M33 processor on the MuscaA board runs Trusted Firmware-M on the Secure domain and Google IoT client on the Non-Secure domain. Zephyr is the RTOS running on the Non-Secure domain. The client requires signed JWT (JSON Web Tokens) to perform handshake with Google MQTT server. The Client running on the Non-Secure side uses JWT sign service in TF-M for signing the token securely. A blink LED secure service in TF-M is invoked whenever the client talks to the service. Steps: 1. After secure boot, Trusted Firmware runs in Secure space and jumps to Zephyr. 2. Zephyr start in Non-Secure. Connect to google server by TCP with TLS handshake 3. Call secure service from Zephyr to TFM for JWT sign 4. Connect to MQTT server and subscribe the device config topic 5. Get the latest configuration from server and publish device status periodically 6. Blink LED by calling secure service when talking with server {F8383}

This page gives information on the Proof Of Concepts (PoCs) based on Trusted Firwamre-M (TF-M). It demonstrates Non-Secure Applications availing Secure Services in Trusted Firmware. The PoC have been demostrated at various events such as ELC at Edinburgh, Linaro Connect at Vancouver. **1. Pelion Client using TF-M **The PoC is done on a [[ https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board | MuscaA board]]. One of the Cortex-M33 processor on the MuscaA board runs Trusted Firmware-M on the Secure domain and Pelion client on the Non-Secure domain. mbedOS is the RTOS running on the Non-Secure domain. The PSK credentials are stored in the Secure domain using the TF-M Secure Storage (SST) service. Pelion client fetches these credentials for establishing secure connection to Pelion portal. Resources (e.g. LED) on board can be accessed using the get/put/post methods over the internet through the Mbed cloud portal, the duration can be changed through pattern resource. Here is a functional block diagram showing the components involved in the PoC. {F8372} Using Secure Storage Service 1.Mbed cloud app fetches PSK from Secure Storage in TFM 2.Keys are used to secure the communication between client and Pelion portal 3.App uses the IP stack (TCP) for communicating with the internet 4.Connection is established between the client and Pelion portal. Client is registered with the portal {F8374} Using Secure LED Service 1.Remote server initiates get/put/post commands for resources over internet 2.Pelion client receives these commands 3.Mbed cloud app uses secure LED service to blink the LED in a predetermined pattern. {F8376} This Proof Of Concept was shown as a Demonstration at ELC-E in Edinburgh in October 2018. The sensor on the MuscaA board was used to detect the motion of a Robot. The motion information was sent to Pelion Cloud using the Secure connection established as described above The Pelion Cloud displays the motion information on a graph as shown in this video [[https://www.youtube.com/watch?v=g1dmE1U3dls&feature=youtu.be | Demo]] **2. Google IoT Client using TF-M **The PoC is done on a [[ https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board | MuscaA board]]. One of the Cortex-M33 processor on the MuscaA board runs Trusted Firmware-M on the Secure domain and Google IoT client on the Non-Secure domain. Zephyr is the RTOS running on the Non-Secure domain. The client requires signed JWT (JSON Web Tokens) to perform handshake with Google MQTT server. The Client running on the Non-Secure side uses JWT sign service in TF-M for signing the token securely. A blink LED secure service in TF-M is invoked whenever the client talks to the service. Steps: 1. After secure boot, Trusted Firmware runs in Secure space and jumps to Zephyr. 2. Zephyr start in Non-Secure. Connect to google server by TCP with TLS handshake 3. Call secure service from Zephyr to TFM for JWT sign 4. Connect to MQTT server and subscribe the device config topic 5. Get the latest configuration from server and publish device status periodically 6. Blink LED by calling secure service when talking with server {F8383}