STM32MP157 SSK Developer Guide
STM32MP157 SSK Developer Guide
Developer Guide
Security Starter Kit with STM32MP1 and OPTIGA™ TPM 2.0
Date: December 3, 2020 | Version 1.8
FINAL
Confidentiality Notice
Copyright (c) 2020 eInfochips. - All rights reserved
This document is authored by eInfochips and is eInfochips intellectual property, including the copyrights in all countries in
the world. This document is provided under a license to use only with all other rights, including ownership rights, being
retained by eInfochips. This file may not be distributed, copied, or reproduced in any manner, electronic or otherwise,
without the express written consent of eInfochips.
Contents
1 INTRODUCTION................................................................................................................. 5
1.1 Purpose of the Document ............................................................................................ 5
1.2 Intended Audience ...................................................................................................... 5
1.3 Prerequisites .............................................................................................................. 5
1.4 Scope of Detailed Design.............................................................................................. 5
2 ENVIRONMENT SETUP ....................................................................................................... 6
3 HARDWARE SETUP ............................................................................................................ 7
3.1 Hardware setup - Security Starter Kit with STM32MP1 and OPTIGA™ TPM 2.0 .................... 7
3.1.1 STM32MP1 board S3 Dip Switch settings for booting from SD Card ........................................... 7
3.1.2 Hardware connection between Avenger96 and OPTIGA™ TPM2.0 ............................................ 7
3.1.3 Powering up the Board ......................................................................................................... 8
3.1.4 Open board's terminal - console (Minicom) on Linux PC ........................................................... 8
4 SOFTWARE SETUP ........................................................................................................... 10
4.1 SSK- STM32MP1 and OPTIGA™ TPM 2.0 Yocto Environment Setup .................................. 10
4.1.1 Pre-requisite ...................................................................................................................... 10
4.1.2 Steps to build the BSP for the SSK- STM32MP1 and OPTIGA™ TPM 2.0 through Yocto .............. 10
4.2 Keys and certificates information. ............................................................................... 12
4.3 OPTIGA™ TPM2.0 Setup Script .................................................................................... 12
4.4 TLS Mutual Authentication & Session Establishment Using H/w Security .......................... 15
4.3 ............................................................................................................................................ 16
4.4.1 Linux Environment: Generate the required keys and certificate .............................................. 16
4.4.1.1 AWS Custom Gateway CA Creation ................................................................................................ 17
4.4.1.2 Registering Your CA Certificate ...................................................................................................... 17
4.4.2 Linux Environment: Secure Device Certificate and Private Key Gen ......................................... 20
4.5 AWS Greengrass Group Creation................................................................................. 24
4.6 AWS Console and Board: Setup AWS IoT for the Demo .................................................. 27
4.6.1 Register the Device Certificate to the AWS IoT for the “thing” ................................................ 28
4.6.2 AWS Console: Create Publish/Subscribe Policy ...................................................................... 32
4.6.3 Linux Environment: Configure the AWS Example Application that Connects to AWS ................. 33
4.6.4 Lambda Functions on AWS IoT Greengrass ........................................................................... 34
4.6.5 On Board: Execute the AWS Example Application .................................................................. 43
5 STM32MP15 SECURE BOOT .............................................................................................. 46
5.1 Secure boot implementation ...................................................................................... 46
4.1 ............................................................................................................................................ 46
5.1.1 Overview ........................................................................................................................... 46
5.1.2 Key Generation .................................................................................................................. 47
5.1.2.1 Install STM32MP Key Generator .................................................................................................... 47
5.1.2.2 STM32MP Key Generator command line interface ........................................................................... 47
5.1.2.3 Extending Public key Hash to bootfs in SD-card ................................................................................ 48
5.1.2.4 Verify Public Key Hash .................................................................................................................. 48
5.1.3 Key Registration ................................................................................................................. 48
5.1.3 .................................................................................................................................................. 48
5.1.3.1 Register hash public key ................................................................................................................ 48
5.1.4 Signing the FSBL and SSBL ................................................................................................... 49
5.1.4 .................................................................................................................................................. 50
5.1.4.1 SSBL signing ................................................................................................................................. 50
5.1.4.2 FSBL signing ................................................................................................................................. 50
FIGURES
TABLES
Definition/Acronym/Abbreviation Description
AV96 Avenger96 Board (with STM32MP157CAC MPU installed)
CSR Certificate Signing Request
DDR Double Data Rate Synchronous Dynamic
FSBL First Stage Boot Loader
PCR Platform Configuration Register
SSBL Second Stage Boot Loader
SSK Security Starter Kit
TF-A Trusted Firmware-A
TFTP Trivial File Transfer Protocol
TPM Trusted Platform module
1 INTRODUCTION
1.1 Purpose of the Document
This guide describes - how to setup the OPTIGA™ TPM 2.0 on Arrow Avenger96 based Yocto platform
with integrated TPM driver and Amazon Greengrass support. This is a hardware layer security for
Avenger96 communication with cloud.
1.2 Intended Audience
This document is for end-user who wants to use OPTIGA™ TPM 2.0, Avenger96 with STM32MP157CAC,
AWS services, enabled with the hardware layer security.
1.3 Prerequisites
Below are the list of Hardware and software needed to enable demonstration of the AWS GG and
OPTIGA™ TPM 2.0 security,
Security Starter Kit Setup will require following:
o Avenger96 board (with the STM32MP157CAC MPU installed)
o Tresor Mezzanine board (with the OPTIGA™ TPM 2.0 installed)
o SD-card
o MicroUSB debug cable
o Power Supply
Linux PC (Minicom for serial console)
Internet connectivity (Wi-Fi/Ethernet) of Board and Linux PC should be on same Network
1.4 Scope of Detailed Design
Integration of AWS IoT Greengrass with OPTIGA™ TPM 2.0 to provide secure, hardware-based
gateway/edge compute device. This integration ensures the use of private key to establish device
identity, which is securely stored in tamper-proof hardware devices, which prevents the device from
being compromised, impersonated and other malicious activities.
2 ENVIRONMENT SETUP
1. Cloud Services – Amazon Web Services (User must have an AWS Account Credentials before
using this Guide)
2. Gateway device - Avenger96 – based on STM32MP157A (96 boards) (Processor Swapped to
STM32MP157CAC for Secure Boot Enable)
3. Hardware security device - Tresor Mezzanine Infineon OPTIGA™ TPM 2.0. (TPM device
swapped with the Infineon OPTIGA™ SLB9670 or SLM9670 TPM2.0)
4. Power Supply –12V-2A 24W AC/DC Power Supply
5. Debug Cable - MicroUSB debug cable
6. HOST PC – Linux as Operating System (Ubuntu 16.04)
3 HARDWARE SETUP
3.1 Hardware setup - Security Starter Kit with STM32MP1 and OPTIGA™ TPM 2.0
3.1.1 STM32MP1 board S3 Dip Switch settings for booting from SD Card
5. After the Avenger96 board boots up, it will display login console on minicom terminal on Linux
PC as shown below.
6. Username for board is “root” without any password
4 SOFTWARE SETUP
4.1 SSK- STM32MP1 and OPTIGA™ TPM 2.0 Yocto Environment Setup
4.1.1 Pre-requisite
Linux PC (x86) having Ubuntu 16.04 LTS installed (to build Yocto image)
Basic understanding of Linux commands
Required steps for building a BSP for ST's development boards can be found here
4.1.2 Steps to build the BSP for the SSK- STM32MP1 and OPTIGA™ TPM 2.0 through Yocto
[Note: Default, Image will be available in the SD-card, But If user wants to install the new image
again on the SD-card or in case the image gets corrupted, then below steps can be handy]
Extracting the tar file, one will find the below contents:
Developer_Guide_STM32MP1_SSK.pdf that has detailed description of all the
components, examples and how to enable all features of the Kit.
Quick_Start_Guide_STM32MP1_SSK.pdf
Firmware_Image
SSK_AWS_Demo
SSK_Cert_And_Config
SSK_Suit_Configuration
Stm32mp1_Yocto_Build
Copyright.txt, the copyright notice
RELEASE_NOTES.txt, information about the release
Linux-PC $ cd Stm32mp1_Yocto_Build/
Linux-PC $ ./build_script_avg.sh
[Note: Please refer the Bitbake User Manual for better understanding of bitbake files, recipes and layers
as well as options to build an image.]
5. Once Yocto build is complete user will get below screenshot. Create SD-card image.
Linux-PC $ cd STM32MP1_SSK_Pkg_Rel_v01/Firmware_Image /
Linux-PC $ sync
10. The SD-card is now ready for use on the Avenger96 board
11. Plug the SD-card in the Avenger96 board
12. and power up the board. The board will be up and running. Launch the Minicom, booting log.
it will display boot up logs and finally ask for login.
root@stm32mp1-av96:~# cd SSK_Suit_Configuration
root@stm32mp1-av96:~#. / SSK_Suit_Configuration.sh
3. Now, it will start installing the package. For the first time - it will take ~20 minutes.
4. After completion of script, it creates Keypair and device certificate using TPM.
Additional Steps:
[Note: If user wants to clear the TPM then below Steps will help for debugging]
7. If TPM is clear then user will get below logs. Again, execute the above steps from 1 to 5 for
setup again as described in 4.3.
4.4 TLS Mutual Authentication & Session Establishment Using H/w Security
Amazon cloud allows customers to use device certificates signed and issued by their own certificate
authority (CA) to connect and authenticate with AWS IoT. This is an alternative to using certificates
generated by AWS IoT and better fits customers’ needs. This method is used by “things” using MQTT
protocol. MQTT is using TLS as a secure transport mechanism. In IoT each “thing” needs to be uniquely
identified by the cloud application and that is realized by using device certificates as identifiers.
During TLS connectivity establishment, AWS IoT authenticates the connecting device by extracting the
device certificate and verifying its signature against a customer preloaded root certificate. Similarly, the
device needs to verify the server certificate against the stored AWS IoT root certificate to confirm the
authenticity of the server to which it connects. TLS mutual authentication requires the device to prove
the ownership of its private key used to form the device certificate and this is being done by signing
some data packets with the private key.
The Avenger96 Gateway with TPM2.0 facilitates the creation and signing of a device certificate. The
device certificate is intended for establishing TLS connections with mutual authentication. The Kit
provides an example of how to use the device certificate and TPM based crypto for establishing a TLS
connection with Amazon AWS IoT (usually used for running MQTT protocol that runs on top of TLS).
The example requires the user to create an AWS account, create an OEM Root CA and upload it to AWS.
The Device Certificate needs to be signed with the private key that created the OEM Root CA so the
two certificates are chained, due to the fact that Amazon AWS does not allow the activation of the
same OEM Root CA for multiple AWS accounts.
Instead, the example guides the user to perform the following steps: create an AWS Custom CA, register
the Custom CA in AWS, provide verification to AWS and create an AWS Device Certificate. Then save
the created AWS Custom CA and AWS Device key and cert in TPM2.0. This way the AWS CAs and the
AWS Device Certificate are unique and can be used with AWS for the Evaluation Kit by multiple users
To set and test the TLS mutual authentication and connectivity to AWS IoT, for this example, users
generate their own AWS Custom CA private key and certificate and AWS device key and certificate,
which must be ECDSA 256{actively using RSA-256 Technique}.
Cert/key Name of cert/key exposed by Description
TPM and AV96
Cloud IoT Root CA root.ca.pem Root CA of the Cloud IoT. It
is used for TLS mutual
authentication.
Gateway Root Certificate/Key rootCA.pem Gateway Root Certificate.
rootCA.key For the Evaluation Kit this
cert is predefined. The
associated private key is
provided as a file for
execution of the payload
verification example
application
Gateway Verification verificationCert.crt Gateway Verification
Certificate/Key verificationCert.key Certificate. For the Evaluation
Kit this cert is predefined. The
associated private key is
provided as a file for
The AWS cloud certificate is preloaded in the AWS. The example uses the following keys and certificates:
1. AWS IoT Root Certificate : Comes preloaded with AWS
2. AWS Custom Gateway CA Key: the user generates this private key. It is used to sign the AWS
Device Certificate and to complete the AWS Custom CA Certificate registration process with
AWS IoT
3. AWS Custom Gateway CA Certificate: the user creates this certificate using the openssl tool.
This certificate needs to be uploaded to the AWS IoT cloud
4. AWS Device Private Key: Private key is generated by user and stored inside TPM securely, not
exposed to outside world
5. AWS Device Certificate: the user creates this certificate. It must be created and signed with the
AWS Custom Gateway CA Key. It is used during the AWS device registration step.
[Note: If you followed the steps in Section 4.3 - OPTIGA™ TPM2.0 Setup Script then move to step
4.4.1.2
[Note: The registered CA certificate must sign Device certificates. It is common for a CA certificate to
be used to create an intermediate CA certificate. If you are using an intermediate certificate to
sign your device certificates, you must register the intermediate CA certificate. Use the AWS IoT
root CA certificate when you connect to AWS IoT even if you register your own root CA certificate.
The AWS IoT root CA certificate is used by a device to verify the identity of the AWS IoT servers ]
Earlier, AWS IoT released support for customers who need to use their own device certificates signed
by their preferred Certificate Authority (CA). This is in addition to the support for AWS IoT generated
certificates. The CA certificate is used to sign and issue device certificates, while the device certificates
are used to connect a client to AWS IoT. Certificates provide strong client side authentication for
constrained IoT devices. During TLS handshake, the server authenticates the client using the X.509
certificate presented by the client.
With this feature, customers with existing devices in the field or new devices with certificates signed by
a CA other than AWS IoT can seamlessly authenticate with AWS IoT. It also provides manufacturers the
ability to provision device certificates using their current processes and then register those device
certificates to AWS IoT. For example, if a customer’s manufacturing lines lack internet connectivity;
they can provision their devices offline with their own CA issued certificates and later register them
with AWS IoT.
This exercise will walk you through an end-to-end process of setting up a client that uses a device
certificate signed by your own CA. First, you will generate a CA certificate that will be used to sign your
device certificate. Next, you will register the CA certificate and then register the device certificates.
After these steps, your device certificate will be ready to connect AWS IoT service.
[Note: If you do not have a CA certificate, you can use OpenSSL tool]
To create a CA certificate
1. Generate a key pair on board at /greengrass/certs.
2. Use the private key from the key pair to generate a CA certificate.
root@stm32mp1-av96:~# openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out
rootCA.pem
To register a CA certificate
Get a registration code from AWS IoT. This code is used as the Common Name of the private key
verification certificate. One can retrieve the registration code using the AWS CLI or from the AWS IoT
Console >> SECURE >> CA >> Register Certificate section.
2. Create a CSR for the private key verification certificate. Set the Common Name field of the
certificate to with your registration code copied from above AWS IoT Console >> SECURE >> CA
>> Register Certificate section.
User needs update some information, including the Common Name for the certificate.
Country Name (2-letter code) [AU]:
State or Province Name (full name) []:
Locality Name (for example, city) []:
Organization Name (for example, company) []:
Organizational Unit Name (for example, section) []:
Common Name (e.g. server FQDN or YOUR name)
[]: XXXXXXXXXXXXMYREGISTRATIONCODEXXXXXX
Email Address []:
root@stm32mp1-av96:~# openssl x509 -req -in verificationCert.csr -CA rootCA.pem -CAkey rootCA.key -
CAcreateserial -out verificationCert.crt -days 500 -sha256
4. In the navigation pane , go to Secure option on IoT Console then select Secure >> CA >>
“Register your CA certificate”, and upload your sample CA certificate and verification
certificate:
4.4.2 Linux Environment: Secure Device Certificate and Private Key Gen
You can use a CA certificate registered with AWS IoT to create a device certificate. The device certificate
must register with AWS IoT before use
root@stm32mp1-av96:~# tpm2_listpersistent
- handle: 0x81000000
name-alg:
value: sha256
raw: 0xb
attributes:
value: fixedtpm|fixedparent|sensitivedataorigin|userwithauth|restricted|decrypt
raw: 0x30072
.
.
.
3. If you want to clear the previous token and handle inside TPM2.0 Chipset then please use below
command
root@stm32mp1-av96:~# pip install pyyaml ; sleep 1 ; pip install cryptography ; sleep 1 ; pip install
paramiko ; sync ;sync
6. Run the script to generate keys and token inside TPM2.0 inside given directory.
root@stm32mp1-av96:~# cd ~/tpm2-pkcs11/tools
7. Soft link the resource manager libraries for listing token from TPM and providing to Board
console.
root@stm32mp1-av96:~#cd /usr/lib/
root@stm32mp1-av96:~# ln -s libtss2-tcti-tabrmd.so.0 libtss2-tcti-tabrmd.so
8. Now for checking the URL’s of token generated we need p11tool and p11-kit and other
packages opensc, Use p11-kit list-modules: command to list the HSI modules available with
tokens.
p11-kit-trust: p11-kit-trust.so
library-description: PKCS#11 Kit Trust Module
library-manufacturer: PKCS#11 Kit
library-version: 0.23
tpm2_pkcs11: libtpm2_pkcs11.so
library-description: TPM2.0 Cryptoki
library-manufacturer: tpm2-software.github.io
library-version: 42.42
token: greengrass
manufacturer: Infineon
model: SLB 9670
serial-number: 0000000000000000
hardware-version: 1.16
firmware-version: 7.40
flags:
rng
login-required
user-pin-initialized
token-initialized
root@stm32mp1-av96:~# cd /usr/lib/engines-1.1/
root@stm32mp1-av96:~# /usr/lib/engines-1.1# ln -s pkcs11.so libpkcs11.so
root@stm32mp1-av96:~# export PKCS11_MODULE_PATH=/usr/lib/libtpm2_pkcs11.so
12. Edit openssl.conf for enabling PKCS11 interface for TPM (Edit only highlightened points)
Open /etc/ssl/openssl.conf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# Note that you can include other files from the main configuration
# file using the .include directive.
#.include filename
openssl_conf = openssl_init
[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/engines-1.1/libpkcs11.so
MODULE_PATH = /usr/lib/pkcs11/libtpm2_pkcs11.so
init = 0
root@stm32mp1-av96:~# cd /greengrass/certs/
root@stm32mp1-av96:~# openssl x509 -req -in deviceCert.csr -CA rootCA.pem -CAkey rootCA.key
-CAcreateserial -out aws_device_cert.pem -days 500 -sha256
[Note: If you don't see the Greengrass node, change to an AWS Region that supports AWS IoT
Greengrass. For the list of supported regions, see [AWS IoT Greengrass] in the Amazon Web
Services General Reference.]
4. On the Set up of your Greengrass group page, choose “Customize” to create a group and an
AWS IoT Greengrass
5. Enter a name for your group (for example, MyFirstGroup_TPM), and then choose Next
7. Select the Greengrass Core as per the Gateway Device running with it
MyFirstGroup_TPM_Core
8. Select Security type as customize to upload the Gateway Device certificate Generated by
OPTIGA™ TPM2.0 and signed with Registered RootCA with AWS depicted in Section 4.4.1
4.6 AWS Console and Board: Setup AWS IoT for the Demo
The user must go through the following steps to set and test the TLS connectivity with AWS IoT
1. Create an Amazon AWS account
2. Sign in to the AWS IoT Console
3. Create (Register) a “thing” in the Thing Registry
4. Register the CA to the AWS IoT.
4.6.1 Register the Device Certificate to the AWS IoT for the “thing”
On the AWS console, after the AWS Custom CA Certificate has been registered and activated, for the
“thing” that has been created, the user must click again on Security as shown in the screenshot below.
1. Then click on “View other options” and then “Use my certificate” (click on “Get started”).
2. As shown in the screenshot below, the user will have to click and select the CA that was just
registered and then click on the bottom blue button “Register certificates”.
3. As per the screen below the user has now the option to select to upload and register the Device
Certificate.
4. Select the AWS Device Certificate, aws_device_cert.pem generated in section 4.4.2, upload it
to the AWS IoT “thing”, and press the Register certificate blue button (check the “Activate all”
radio button)
5. At this stage, the AWS IoT cloud has a “thing” ready to allow a device to connect to it: the device
is registered with an active certificate.
For this example, device needs to be attached to a policy that allows them to subscribe and publish. To
accomplish this:
1. Create a policy that allows subscription and publishing to a topic such as in the example policy
shown in the image:
4.6.3 Linux Environment: Configure the AWS Example Application that Connects to AWS
To enable and use the TPM as Hardware Security Integration for Gateway (Device Demo) with AWS
1. Please ensure all certificate and keys generated from section 4.4.1 and 4.4.2 are placed inside
/Greengrass/certs/
2. Enable it in the AWS IoT Greengrass config. Edit /Greengrass/config/config.json and replace the
configuration with the content based on your OpenSSL configuration and location of the keys.
A complete example of the AWS IoT Greengrass configuration with the setup completed in the
preceding sections resembles the following:
root@stm32mp1-av96: vi /Greengrass/config/config.json
{
"coreThing" : {
"thingArn"
:"arn:aws:iot:<AWS_REGION>:<AWS_ACCOUNT_NUMBER>:thing/<GG_Thing_Name>",
"iotHost" : "XXXXXXXXXXXXXXX-ats.iot.us-east-1.amazonaws.com",
"ggHost" : "greengrass-ats.iot.ap-south-1.amazonaws.com",
"keepAlive" : 600
},
"runtime" : {
"cgroup" : {
"useSystemd" : "yes"
}
},
"managedRespawn" : false,
"crypto" : {
"PKCS11": {
"OpenSSLEngine": "/usr/lib/engines-1.1/pkcs11.so",
"P11Provider": "/usr/lib/pkcs11/libtpm2_pkcs11.so",
"SlotLabel": "greengrass",
"SlotUserPin": "1234"
},
"principals" : {
"IoTCertificate" : {
"privateKeyPath" :
"pkcs11:model=SLB9670;manufacturer=Infineon;token=greengrass;object=greenkey;type=private;
pin-value=1234",
"certificatePath" : "file:///greengrass/certs/aws_device_cert.pem"
}
},
"caPath" : "file:///greengrass/certs/root.ca.pem"
}
}
1. Downloaded the AWS IoT Greengrass Core SDK for Python to your computer.
3. Copy the Greengrass SDK folder into the HelloWorld folder that contains
greengrassHelloWorld.py.
4. To create the Lambda function deployment package, save greengrassHelloWorld.py and the
Greengrass SDK folder to a compressed zip file named hello_world_python_lambda.zip. The
python file and Greengrass SDK folder must be in the root of the directory.
2. Choose Save
4. For Version description, enter First version, and then choose Publish.
Name the alias GG_HelloWorld, set the version to 1 (which corresponds to the
version that you just published), and then choose Create.
Note: AWS IoT Greengrass does not support Lambda aliases for $LATEST versions.
6. In the AWS IoT console, under Greengrass, choose Groups, and then choose the group that
you created in above Steps.
On the group configuration page, choose Lambdas, and then choose Add Lambda.
Search for the name of the Lambda you created in the previous step
(Greengrass_HelloWorld, not the alias name), select it, and then choose Next:
For the version, choose Alias: GG_HelloWorld, and then choose Finish. You should see
the Greengrass_HelloWorld Lambda function in your group, using the GG_HelloWorld
alias.
Keep the default values for all other fields, such as Run as, Containerization, Input
payload data type, and choose Update to save your changes.
8. On the group configuration page, choose Subscriptions, and then choose Add your first
Subscription.
9. To Select a target, choose Select. Then, on the Service tab, choose IoT Cloud, and then choose
next.
Choose Finish
10. Configure the group's logging settings. User can configure AWS IoT Greengrass system
components and user-defined Lambda functions to write logs to the file system of the core
device.
On the group configuration page, choose Settings.
For Local logs configuration, choose Edit.
On the Configure Group logging page, choose Add another log type.
For event source, choose User Lambdas and Greengrass system, and then choose Update.
Keep the default values for logging level and disk space limit, and then choose Save.
Disable the Stream Manager Status.
If the output contains a root entry for /Greengrass/ggc/packages/1.10.0/bin/daemon, then the daemon
is running.
root@stm32mp1-av96:~# cd /Greengrass/ggc/core/
root@stm32mp1-av96:~#./greengrassd start
2. In the AWS IoT console, on the group configuration page, from Actions, choose Deploy.
3. On the Configure how devices discover your core page, choose Automatic detection. This
enables devices to automatically acquire connectivity information for the core, such as IP
address, DNS, and port number. Automatic detection is recommended, but AWS IoT
Greengrass also supports manually specified endpoints. You are prompted for the discovery
method for first time when group is deployed.
4. The first deployment might take a few minutes. When the deployment is complete, you
should see
5. Successfully completed in the Status column on the Deployments page:
6. Verify the Lambda Function Is Running on the Core Device with H/w Security enabled with
TPM.0 security keys.
7. From the navigation pane of the AWS IoT console, choose Test.
[Note: Assuming the Lambda function is running on your device, it publishes messages similar to the
following to the hello/world topic]
Display MQTT messages on the screen like “Message from Avenger96”
This section is a practical example to illustrate the construction of a secure boot image and to configure
the target device to run securely, which is possible because of the Trusted Firmware-A (TF-A) and the
STM32 KeyGen tool. This document targets the Secure Boot feature on the following applications
processors from the STM32MP157CAC family.
This application note only demonstrates the secure boot solution on the Avenger96 and
STM32MP157CAC processors, as well as some trusted features for secure boot. It focuses on:
Target audience:
Someone who has knowledge of normal booting process, familiar with signing image tools, and fuse
related concepts. User should be familiar with the basics of digital signatures and public key certificates.
[Note: See Appendix Section 6.5 for more information on secure boot environment]
5.1 Secure boot implementation
5.1.1 Overview
STM32 MPU provides authentication processing with ECDSA [1] verification algorithm, based on ECC [2].
ECDSA offers better result than RSA with a smaller key. STM32 MPU relies on a 256 bits ECDSA key.
The algorithm selection is done via the signed binary header, as shown in STM32 header (subchapter
in this same article).
Linux-PC $ cd /home/<username>/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin
Make a new directory with name “secure_keys” and run below command.
User will see the following on his screen if key pair generated successfully fine, please note down the
key type.
-------------------------------------------------------------------
STM32MP Key Generator v1.0.0
-------------------------------------------------------------------
Copy the pubKeyHash.bin in to bootfs of SD-card partition and boot the board
Output user can check and validate with one copied to bootfs while mmc read
PKH file (pubKeyhash.bin) must be available in a file system partition (like bootfs) on a storage device
(like SD-card) before proceeding.
Plug the SD-card into the Avenger96 board, power on the board and pause the u-boot console by
pressing any key while UBoot log is seen on the serial debug console
root@stm32mp1-av96:~#
$ STM32MP> ext4load mmc 0:4 0xc0000000 pubKeyhash.bin
32 bytes read in 0 ms
Read loaded key from DDR to confirm it is valid (without writing it in OTP)
root@stm32mp1-av96:~#
$ STM32MP> stm32key read 0xc0000000
root@stm32mp1-av96:~#
$ STM32MP> stm32key fuse -y 0xc0000000
SSBL: u-boot-stm32mp157a-av96-trusted.stm32
Yocto Path: Avenger96/build-openstlinuxweston-stm32mp1-av96 /tmp-
glibc/deploy/images/stm32mp1-av96/u-boot-stm32mp157a-av96-trusted.stm32
For more info about Avenger96 Image Partition please review the Yocto file named
“README.HOW_TO.txt” found in this directory or path:
Avenger96/layers/meta-st/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-stm32mp/
Go to path /home/<user>STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin
Linux-PC $ cd /home/<username>/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin
FSBL:
sudo dd if=tf-a-stm32mp157a-av96-trusted-signed.stm32 of=/dev/sdb1 bs=1M conv=fdatasync
status=progress && sync
SSBL:
sudo dd if=u-boot-stm32mp157a-av96-trusted-signed.stm32 of=/dev/sdb3 bs=1M conv=fdatasync
status=progress && sync
If the image authentication fails the boot stage traps the CPU and no more trace is displayed.
Without any other modification, the device is able to perform image authentication but non-
authenticated images can still be used and executed: the device is still opened, let's see this as a kind
of test mode to check that the PKH is properly set.
As soon as the authentication process is confirmed, the device can be closed and the user forced to use
signed images.
OTP WORD0 bit 6 is the OTP bit that closes the device. Burning this bit will lock authentication
processing and force authentication from the Boot ROM. Non signed binaries will not be supported
anymore on the target.
To program this bit, the STM32CubeProgrammer or U-Boot command line interface can be used.
Here is how to proceed with U-Boot:
Avenger96 Board
At power-up, the Avenger96 device CSU ROM code loads the FSBL. The FSBL loads U-Boot, and U-Boot
loads the Linux kernel, root file system, device tree and Linux application software. In one approach to
booting with a chain of trust, the following steps occur:
1. The device hardware measures the Kernel Image.
2. The Kernel Image authenticated is being hashed.
3. The PCR API pushes the Kernel Image Hash measurement to the TPM.
If values are similar, the Platform is secure and no tamper has occurred.
6 APPENDIX
6.1 Avenger – 96 Boards
The STM32MP157A is a highly integrated multi-market system-on-chip designed to enable secure and
space constraint applications within the Internet of Things. Avenger96 board features dual Arm Cortex-
A7 cores and an Arm Cortex-M4 core. In addition, an extensive set of interfaces and connectivity
peripherals are included to interface to cameras, touchscreen displays and MMC/SD-cards. It also fully
supports wireless communication, including WLAN and BLE.
Arrow’s Avenger96 module integrates the high-end STM32MP157 module, which offers dual 650MHz
Cortex-A7 cores and a 209MHz Cortex-M4 chip with an FPU, MPU, and DSP instructions. The
STM32MP157 model includes the optional 533MHz Vivante 3D GPU with support for OpenGL ES 2.0
and 24-bit parallel RGB displays at up to WXGA (1280×800) at 60fps. This is also the only model with
MIPI-DSI support.
96Boards (http://www.96Boards.org) is a 32-bit and 64-bit ARM® Open Platform hosted by Linaro TM
with the intension to serve the software/maker and embedded OEM communities
Processor
STM32MP157AAC to be replaced with Chipset STM32MP157CAC in order to enable secure
boot feature
2x ARM®Cortex-A7 up to 650 MHz
1x ARM®Cortex-M4 up to 200 MHz
1x 3D GPU Vivante® @ 533 MHz -OpenGL® ES 2.0
Memory/Storage
eMMC v4.51: 8 GbyteSD 3.0 (UHS-I)
QSPI: 2Mbyte
EEPROM: 128 byte
microSD Socket: UHS-1 v3.01
RAM: 1024 Mbyte @ 533MHz
I/O Interfaces
Host: 2x type A 2.0 high-speed and OTG, 1x type micro-B 2.0 high-speed
One 40-pin Low Speed (LS) expansion connector (UART, SPI, I2S, I2C x2, GPIO x12, DC power)
One 60-pin High Speed (HS) expansion connector (4L-MIPI DSI, USB, I2C x2, 4LMIPI CSI, 1-SPI)
The board can be made compatible as an add-on mezzanine board
Connectivity
Bluetooth 4.2 (Bluetooth Low Energy)
High performance 2.4 GHz and 5 GHz WLAN
Ethernet support 10/100/1000 Mbps speed
Video
HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
Operating Temp: 0 - 40 °C
Software
U-Boot version: U-Boot 2018.09-stm32mp-r2
Linux version: Linux stm32mp1-av96 4.14.48
AWS IoT Greengrass software extends cloud capabilities to local devices. This allows the cloud-based
management of application logic which can be used for any of the following and more:
to collect and analyze data
react autonomously to local events
Communicate securely on local networks
AWS Lambda functions and pre-built connectors to create server less applications that are
deployed to devices for local execution
provides a local pub/sub message manager that can intelligently buffer messages to preserve
inbound and outbound messages to the cloud in case there is no connectivity to cloud
The following diagram shows the basic architecture of AWS IoT Greengrass.
The Tresor Mezzanine Board provides state-of-the-art secure elements to 96Boards board. The board
is as shown in Figure 2.
The board is equipped with three separate chips that can provide security features:
The SLB9670x provides Trusted Platform Module (TPM) 2.0 functionality through SPI
communication on the standard 96Boards LS expansion connector.
The SLB9645x TPM 1.2 chip communicates via I2C on the standard 96Boards low-speed
expansion connector.
The SLS32AIA020A TRUST-E authentication chip, shares the same I2C bus with the TPM 1.2
module.
A cryptographic processor is present on most commercial PCs and servers. A typical crypto processor
has three key cryptographic capabilities
Establishing a root of trust
Secure boot
Device identification
Each layer must trust the layer below, as illustrated in the following diagram.
At the root of this chain is the hardware, which has to be inherently trusted and forms the base on
which the chain of trust has been established.
Secure boot
A secured boot builds on the underlying notion of a root of trust to protect the boot process from being
compromised on the device.
In case a chain of trust is broken, the boot process is aborted, and the device attempts to go back to its
last known good state. An extension to secured boot process is a measured boot – where the device
does not halt the boot process. Instead, it records the identity of each component that participates in
the boot process so that these component identities can be verified later against a list of approved
component identities for that device. This is called a measured boot.
Device identification
Device identification steps are comprised as follows:
Check the identity of the device that is communicating with the messaging gateway.
Generate key pairs for the devices, which are then used to authenticate and encrypt the
traffic
TPM stores the keys in tamper-resistant hardware.
The keys are generated using TPM itself and are thereby protected from being retrieved by
external programs.
The rest of this post focuses on how to integrate and use features of TPMs to protect the edge gateways
running AWS IoT Greengrass. This integration uses the PKCS#11 protocol as the interface to the TPM.
6.5 Boot chains Environment overview
Refer to the security overview for an introduction of the secure features available on STM32MP15,
from the secure boot up to trusted applications execution.
[Note: We have swapped the MPU IC on the AVENGER96 board from the STM32MP157A to
STM32MP157CAC, which supports secure boot.]
STM32 Header
Each binary image (signed or not) loaded by ROM code and by TF-A need to include a specific
STM32 header added on top of the binary data. The header includes the authentication
information.
Signature is calculated from first byte of header version field to last byte of image given by
image length field.
32-bit sum of all payload bytes accessed as 8-bit unsigned numbers, discarding any overflow
bits. Used to check the downloaded image integrity when signature is not used (if b0=1 in
Option flags).
Length is the length of the built image; it does not include the length of the STM32 header.
This field is not used by ROM code.
Image version number is an anti-rollback monotonic counter. The ROM code checks that it is
higher or equal to the monotonic counter stored in OTP.
Enabling signature verification is mandatory on secure closed chips.
This field is an extract of PEM public key file that only kept the ECC Point coordinates x and y
in a raw binary format (RFC 5480). This field will be hashed with SHA-256 and compared to
the Hash of pubKey that is stored in OTP.
This padding forces STM32 header size to 256 bytes (0x100).
Starting from a root of trust (typically the SoC Boot ROM), each software stage during the boot process
(BL1, BL2, BL31, BL33/U-Boot, Linux) is supposed to do some measurements and store them in a safe
place. A measure is just a digest (let’s say, a SHA256) of a memory region. Usually each stage will ‘digest’
the next one. Each digest is then sent to the TPM, which will merge this measurement with the previous
ones.
The hardware feature used to store and merge these measurements is called Platform Configuration
Registers (PCR). At power-up, a PCR is set to a known value (either 0x00s or 0xFFs, usually). Sending a
digest to the TPM is called extending a PCR because the chosen register will extend its value with the
one received with the following logic:
This way, a PCR can only evolve in one direction and never go back unless the platform is reset.
In a typical measured boot flow, a TPM can be configured to disclose a secret only under a certain PCR
state. Each software stage will be in charge of extending a set of PCRs with digests of the next software
stage. Once in Linux, user software may ask the TPM to deliver its secrets, but the only way to get them
is having all PCRs matching a known pattern. This can only be obtained by extending the PCRs in the
right order, with the right digests.
7 REFERENCES
[1] https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html
[2] https://wiki.st.com/stm32mpu/index.php/STM32MP1_Distribution_Package
[3] https://git.yoctoproject.org/cgit/cgit.cgi/meta-security
[4] https://github.com/dh-electronics/meta-av96/tree/master/meta-av96.thud
[5] https://github.com/STMicroelectronics/meta-predmnt
[6] https://wiki.st.com/stm32mpu/wiki/How_to_integrate_AWS_IoT_Greengrass
[7] https://github.com/dh-electronics/manifest-av96
[8] https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-dg.pdf
[9] https://docs.aws.amazon.com/iot/latest/developerguide/register-CA-cert.html
[10] https://www.infineon.com/dgdl/Infineon-SLB%209670VQ2.0-DataSheet-v01_04-
EN.pdf?fileId=5546d4626fc1ce0b016fc78270350cd6
[11] https://github.com/tpm2-software
[12] https://www.96boards.org/product/avenger96/
[13] https://www.96boards.org/product/tresor/
[14] https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm
[15] https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
[16] https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Purpose