Secure AWS IoT Connectivity

Transcription

1 SLS 32AIA020X2/4 Secure AWS IoT Connectivity Description The purpose of this application note is to describe how to securely connect a Raspberry Pi with Amazon Web Services (AWS) IoT using OpenSSL and an Infineon hardware security module: the Infineon OPTIGA Trust X. AWS IoT mandates a Public-Key Infrastructure (PKI) and Transport Layer Security (TLS) to authorize IoT devices. This document describes the set-up of the PKI, the personalization of the Infineon OPTIGA Trust X the system integration of the Infineon OPTIGA Trust X with a Raspberry Pi, OpenSSL and AWS IoT. The use of hardware-security by means of Infineon OPTIGA Trust X introduces a strong root of trust, strong IoT device authentication, and secured communication with AWS IoT. For commercialization of the solution please contact your nearest Infineon representative or send an to support@infineon.com. Infineon OPTIGA Trust X Features Public key cryptography using Elliptic Curve Cryptography (ECC) Transport Layer Security (TLS) Version 1.2 EC-based X.509 certificates for TLS connection Forward secrecy using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) I2C Interface Up to 10 KB user memory Common Criteria Certified EAL6+ (high) hardware Applications Cloud device connectivity Consumer electronics Smart home s Please read the Important Notice and Warnings at the end of this document <Revision 1.2>

2 Table of Contents Description... 1 Infineon OPTIGA Trust X Features... 1 Applications 1 Table of Contents Introduction to AWS IoT Software Overview Hardware Setup AWS IoT Public Key Infrastructure Set-Up Create Folder Structure Certificate Authority (CA) Prepration Create a CA using OpenSSL Create a CA Certificate Register a Self-Signed CA Certificate using Web-based AWS Generate the Self-Signed CA Certificate Upload and Activate the Self-Signed CA Certificate in AWS IoT Registering CA Certificate using AWS Command Line Interface (CLI) Get the CA Registration Code Upload and Activate the CA Certificate AWS IoT MQTT Client Configuration Hardware Setup Install Trust X OpenSSL Engine Create the Thing Certificate Using Trust X Create an AWS IoT Thing Create an AWS IoT policy Upload the Thing certificate to AWS IoT Testing the AWS IoT MQTT Connectivity Troubleshooting OpenSSL.SSL.Error: [('SSL routines', 'ssl3_read_bytes', 'sslv3 alert certificate unknown')] Conclusion Revision History s 2 <Revision 1.2>

3 1 Introduction to AWS IoT AWS IoT is a public cloud service to connect IoT devices and other AWS services. It provides a managed Message Queuing Telemetry Transport (MQTT) server, plus authentication, authorization and device management services. AWS IoT provides secured, bi-directional communication between an Internet-connected Thing (the terminology of Thing can be used interchangabily with client, device, or endpoint) and the AWS cloud. This enables collection of telemetry data from multiple Things, and storage and analysis of the data. Users can also create applications that enable the control of these devices from mobile phones or tablets. Things report their state by publishing JavaScript Object Notation (JSON) messages on MQTT topics. Each MQTT topic has a hierarchical name that identifies the Thing whose state is being updated. When a message is published on an MQTT topic, the message is sent to the AWS IoT MQTT message broker, which is responsible for sending all messages published on an MQTT topic to all clients subscribed to that topic. Communication between a Thing and AWS IoT is protected through the use of Transport Layer Security (TLS) and mutual authentication using X.509 certificates. AWS IoT can generate a certificate for you or you can use your own. In either case, the certificate must be registered and activated with AWS IoT, and then copied into your Thing. When your Thing communicates with AWS IoT, it presents the certificate to AWS IoT as a credential to get authenticated and authorized. 1.1 Software Overview The software and configuration in this has been tested with the following setup on a Raspberry Pi 3. The latest version of these software packages can be downloaded and installed from the internet. In addition, it is essential to register an AWS Account to begin the development. The free tier is sufficient to get started. Raspbian v7+ Python 3.5 or newer OpenSSL (tested with version 1.1.0f) AWS Command Line Interface (CLI) [optional] List of scripts, configuration and source codes mentioned in this : Support scripts o create_aws-csr+cert.sh o create-trustx-csr.sh Configuration files o openssl.cnf Software modules (including source code): o Trust X OpenSSL Engine o Trust X integrated AWS Python MQTT SDK (Apache License Version 2.0) s 3 <Revision 1.2>

4 1.2 Hardware Setup Table 1 explains the electrical connection between the Trust X and the Raspberry Pi 3. Figure 1 Pinout of Raspberry Pi 3 and Trust X Note: Raspberry Pi 3 has I2C pull-up resistors populated on the GPIO pins. Table 1 Electrical connection of Raspberry Pi to Trust X Trust X Pin Raspberry Pi Pin Comments Supply Voltage (GND) 02 - Not Connected Serial Data Line (SDA) 04 - Not Connected 05 - Not Connected 06 - Not Connected 07 - Not Connected Serial Clock Line (SCL) Active Low Reset (RST) Supply Voltage (VCC) s 4 <Revision 1.2>

5 2 AWS IoT Public Key Infrastructure Set-Up AWS IoT uses X.509 certificates for asymmetric-key based authentication. There are 3 types of X.509 certificate models supported by AWS IoT: 1. AWS IoT One-Click certificate creation 2. AWS IoT generates a certificate with Certificate Signing Request (CSR) 3. Use Your Own Certificate with customer root CA and Trust X signed certificate signing requests (CSRs) In the first method, AWS IoT generates the public-private key pair. The device certificate together with the private key is downloaded into the client firmware. This generally has the weakest security level, as the private key is generated on remote AWS servers, although it should be kept secret to the IoT device. For the second method (create with CSR), the key pair is generated by the user and the device certificate is generated by uploading the CSR to AWS IoT. In this case, the secret private key is generated by the user and this secret key is also loaded into the firmware of the IoT device. The third method allows the private key to be generated and stored on an external security controller, such as the Trust X. This method is one of the strongest client authentication methods, because the private key never leaves the secured storage of the Trust X. The private key is generated, stored, and processed always inside the strongly protected security controller. In order to set up your own public-key infrastructure (PKI) and to use your own certificate with AWS IoT, the following general steps need to be conducted: 1. Creating the CA Certificate 2. Register the CA Certificate with AWS IoT 3. Create a Device Certificate Using Your CA Certificate 4. Registering the Device Certificate with AWS IoT In the following sub-sections, the above steps will be explained in detail. 2.1 Create Folder Structure Move the Resource folder of this application note to the Raspberry Pi using a USB thumbdrive. $ cd $HOME $ mkdir trustx-aws-appnote $ cd trustx-aws-appnote $ cp R /media/pi/ YOUR_DRIVE_NAME /Resources/ 2.2 Certificate Authority (CA) Prepration In this, the CA creation is done using the Raspberry Pi with OpenSSL. However, it is important to note that CA prepration can be performed on any system with CA creation software. Prepare the CA directory on the Raspberry Pi with following sequence of commands: $ mkdir -p Pki/root/ca $ cd Pki/root/ca/ $ mkdir certs crl newcerts private $ chmod 700 private $ touch index.txt $ chmod 777 index.txt s 5 <Revision 1.2>

6 $ touch index.txt.attr $ touch serial $ chmod 777 serial $ echo 1000 > serial Verify the created directory structure by comparing it with the sample output below using the command: $ ls -l drwxr-xr-x 2 pi pi 4096 Nov 28 09:53 certs drwxr-xr-x 2 pi pi 4096 Nov 27 08:12 crl -rwxrwxrwx 1 pi pi 0 Nov 27 08:12 index.txt -rw-r--r-- 1 pi pi 0 Nov 29 06:27 index.txt.attr drwxr-xr-x 2 pi pi 4096 Nov 27 08:12 newcerts drwx pi pi 4096 Nov 27 08:18 private -rwxrwxrwx 1 pi pi 5 Nov 27 08:14 serial Create a CA using OpenSSL The CA is created based on the OpenSSL configuration file. By modifying the configuration file, it is possible to specify how the CA process is executed. A sample of generic configuration file will be provided with the as reference (see Resources/Configuration/openssl.cnf). Note: Note: Don t forget to update the directory and file location in the configuration file. $ vi openssl.cnf [ ca ] default_ca = CA_default [ CA_default ] # Directory and file locations. dir = /home/pi/trustx-aws-appnote/pki/root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.key.pem certificate = $dir/certs/ca.cert.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 999 preserve = no policy = policy_loose s 6 <Revision 1.2>

7 [ policy_strict ] # The root CA should only sign intermediate certificates that match. # See the POLICY FORMAT section of `man ca`. countryname = match stateorprovincename = match organizationname = match organizationalunitname = optional commonname = supplied address = optional [ policy_loose ] # Allow the intermediate CA to sign a more diverse range of certificates. # See the POLICY FORMAT section of the `ca` man page. countryname = optional stateorprovincename = optional localityname = optional organizationname = optional organizationalunitname = optional commonname = supplied address = optional [ req ] # Options for the `req` tool (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions = v3_ca [ req_distinguished_name ] # See < countryname = Country Name (2 letter code) stateorprovincename = State or Province Name localityname = Locality Name 0.organizationName = Organization Name organizationalunitname = Organizational Unit Name commonname = Common Name address = Address # Optionally, specify some defaults. countryname_default = AG stateorprovincename_default = Germany localityname_default = 0.organizationName_default = #organizationalunitname_default = # address_default = [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectkeyidentifier = hash authoritykeyidentifier = keyid:always,issuer basicconstraints = critical, CA:true #keyusage = critical, digitalsignature, crlsign, keycertsign keyusage = critical, keycertsign [ v3_intermediate_ca ] s 7 <Revision 1.2>

8 # Extensions for a typical intermediate CA (`man x509v3_config`). subjectkeyidentifier = hash authoritykeyidentifier = keyid:always,issuer basicconstraints = critical, CA:true, pathlen:0 keyusage = critical, digitalsignature, crlsign, keycertsign [ usr_cert ] # Extensions for client certificates (`man x509v3_config`). basicconstraints = CA:FALSE nscerttype = client, nscomment = "OpenSSL Generated Client Certificate" subjectkeyidentifier = hash authoritykeyidentifier = keyid,issuer keyusage = critical, nonrepudiation, digitalsignature, keyencipherment extendedkeyusage = clientauth, protection [ aws_node_cert ] # Extensions for gateway certificates (`man x509v3_config`). basicconstraints = CA:FALSE nscerttype = server subjectkeyidentifier = hash authoritykeyidentifier = keyid,issuer:always keyusage = critical, digitalsignature, keyencipherment Create a CA Certificate First, the cryptographic root key pair is created. This key pair is stored in the file ca.key.pem. Then, the private key is used to sign a self-signed CA certificate, resulting the the CA certificate ca.cert.pem. Together, this pair of private key and certificate forms the identity of the Certificate Authority (CA). Attention: In a production environment, this pair of information must be stored securely. Move to the CA directory: $ cd $HOME/trustx-aws-appnote/Pki/root/ca Conduct the following commands to generate the key and certificate: Generate the ECC private key for the CA: $ openssl ecparam -genkey -name secp384r1 -out private/ca.key.pem Generate the CA certificate using the previously generated private key: $ openssl req -config $HOME/trustx-aws-appnote/Resources/Configuration/openssl.cnf -key private/ca.key.pem -new -x509 -days sha256 -extensions v3_ca -out certs/ca.cert.pem You will be presented with a dialog with the user input data for the CA details. Display status of the CA certificate: $ openssl x509 -noout -text -in certs/ca.cert.pem s 8 <Revision 1.2>

9 Sample CA certificate output: Certificate: Data: Version: 3 (0x2) Serial Number: e7:92:ad:28:5c:f4:1e:ec Signature Algorithm: ecdsa-with-sha256 Issuer: C = SG, ST = Singapore, L = Singapore, O = Infineon Technologies Pte Ltd, OU = Chip Card & Security, CN = OPTIGA Trust X, address = XXXXXXXXX Validity Not Before: Nov 27 08:31: GMT Not After : Nov 22 08:31: GMT Subject: C = SG, ST = Singapore, L = Singapore, O = Infineon Technologies Pte Ltd, OU = Chip Card & Security, CN = OPTIGA Trust X, address = XXXXXXXXXXXX Subject Public Key Info: Public Key Algorithm: id-ecpublickey Public-Key: (384 bit) pub: 04:1a:47:ae:0c:46:3e:b6:ba:ca:fa:fc:47:11:c8: 9d:8e:1d:7f:57:ad:36:86:aa:fb:81:6f:5a:3e:b4: d6:e0:33:36:1c:14:f1:b1:df:b1:c1:dc:d2:a9:4c: 69:4d:d9:db:40:3c:57:c9:f2:25:dd:df:26:87:54: 21:92:70:fa:d5:5f:e1:5d:6a:e2:31:2a:c1:4c:9b: 10:74:50:f1:6e:63:38:28:aa:f6:97:44:1c:e8:94: ab:28:ca:b9:62:14:ac ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 6F:EC:59:93:13:35:F0:BB:ED:BF:70:2E:82:73:B7:24:B8:28:13:DC X509v3 Authority Key Identifier: keyid:6f:ec:59:93:13:35:f0:bb:ed:bf:70:2e:82:73:b7:24:b8:28:13:dc X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign Signature Algorithm: ecdsa-with-sha256 30:64:02:30:08:3f:2e:b5:19:ae:08:d9:58:57:93:80:59:47: 54:0d:9e:c4:d5:dd:05:cd:48:d3:41:ef:92:27:6c:f4:78:3c: e9:8f:93:e2:1f:54:14:cf:c4:7c:64:0f:4a:9c:bc:86:02:30: 46:41:fb:49:d4:b4:8c:6e:92:a7:45:2d:09:df:11:e5:ed:5b: 60:05:ee:84:42:10:da:2d:30:17:3f:03:84:88:76:d6:7a:29: e5:41:e6:55:ec:1f:ee:b6:ef:9f:93:6c s 9 <Revision 1.2>

10 2.3 Register a Self-Signed CA Certificate using Web-based AWS This section explains the AWS IoT configuration using the web-based AWS IoT Console. AWS IoT also provides a more efficient and advanced method using a command-line based tool. The sample commands can be found in Section 2.4. So you have to either follow the steps in this Section or Section 2.4. In order to register a self-signed CA Certificate with AWS IoT, it is necessary to obtain a registration code from AWS IoT. It is important to select the apporiate region for the AWS endpoint. The registration code will be used as the Common Name of the private key verification certificate. This code can be found in Step 2 of the instruction step provide in AWS web protal. Figure 2 Getting the CA Registration Code s 10 <Revision 1.2>

11 2.3.1 Generate the Self-Signed CA Certificate To register the self-signed CA certificate, AWS IoT demands two files to be uploaded: the CA certificate the verification certificate; with the registration code (obtained in earlier step) as the common name of the verification certificate Without transmitting the secret key to AWS IoT, the verification certificate allows AWS IoT to verify that the CA certificate holder also holds the secret, private key (because only the entity in possession of the private key was able to sign and issue the certificate with the registration code). To ease the process of CSR and certificate generation, use the script provided with the for CA creation and certificate signing. The script needs the execute permission and should be placed in the root/ca folder. Change to the following directory and make files executable: $ cd $HOME/trustx-aws-appnote/Resources/Scripts $ chmod +x *.sh Create the CA CSR followed by generation of root CA certificate using the script (this script should be modified according to you registration code): $./create_aws-csr+cert.sh Exaplanation of create_aws-csr+cert.sh script details: Creating the CSR with the Common Name from AWS IoT: $ openssl req -new -subj "/CN=04102b8a5e78e58028d8db2941e0d9900b7abed15e776f7f6b93a595cf6e0a4f" -key $HOME/trustx-aws-appnote/Pki/root/ca/private/ca.key.pem -out aws-reg-code.csr Sign the CSR using the CA Private Key: $ openssl x509 -req -in./aws-reg-code.csr -CA $HOME/trustx-aws-appnote/Pki/root/ca/certs/ca.cert.pem -CAkey $HOME/trustx-aws-appnote/Pki/root/ca/private/ca.key.pem -CAcreateserial -out aws-reg-code.cert.pem -days 500 -sha256 Sample output: $ openssl x509 -req -in./aws-reg-code.csr -CA $HOME/trustx-aws-appnote/Pki/root/ca/certs/ca.cert.pem -CAkey HOME/trustx-aws-appnote/Pki/root/ca/private/ca.key.pem -CAcreateserial -out aws-reg-code.cert.pem -days 500 -sha256 Signature ok subject=cn = 04102b8a5e78e58028d8db2941e0d9900b7abed15e776f7f6b93a595cf6e0a4f Getting CA Private Key Sample directory contents: -rw-r--r-- 1 pi pi 692 Dec 9 08:29 aws-reg-code.cert.pem -rw-r--r-- 1 pi pi 513 Dec 9 08:29 aws-reg-code.csr -rwxr-xr-x 1 pi pi 517 Dec 9 08:29 create_aws-csr+cert.sh -rwxr-xr-x 1 pi pi 609 Dec 9 06:53 create-trustx-csr.sh s 11 <Revision 1.2>

12 Sample content of the CSR: $ openssl x509 -in aws-reg-code.cert.pem -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: b3:e7:3a:91:34:99:20:8f Signature Algorithm: ecdsa-with-sha256 Issuer: C = SG, ST = Singapore, L = Singapore, O = Infineon Technologies Pte Ltd, OU = Chip Card & Security, CN = OPTIGA Trust X, address = XXXXXXXXXXXXXXXXXXX Validity Not Before: Nov 29 07:13: GMT Not After : Apr 13 07:13: GMT Subject: CN = 04102b8a5e78e58028d8db2941e0d9900b7abed15e776f7f6b93a595cf6e0a4f Subject Public Key Info: Public Key Algorithm: id-ecpublickey Public-Key: (384 bit) pub: 04:1a:47:ae:0c:46:3e:b6:ba:ca:fa:fc:47:11:c8: 9d:8e:1d:7f:57:ad:36:86:aa:fb:81:6f:5a:3e:b4: d6:e0:33:36:1c:14:f1:b1:df:b1:c1:dc:d2:a9:4c: 69:4d:d9:db:40:3c:57:c9:f2:25:dd:df:26:87:54: 21:92:70:fa:d5:5f:e1:5d:6a:e2:31:2a:c1:4c:9b: 10:74:50:f1:6e:63:38:28:aa:f6:97:44:1c:e8:94: ab:28:ca:b9:62:14:ac ASN1 OID: secp384r1 NIST CURVE: P-384 Signature Algorithm: ecdsa-with-sha256 30:65:02:31:00:95:41:a3:fa:c3:1e:e3:63:a4:25:8f:cf:4e: 37:6e:19:24:95:3d:f2:26:cb:e6:3c:4b:54:1a:fc:7b:b7:33: b0:9d:66:f5:ea:ff:14:68:36:61:4c:29:f6:49:9e:30:bd:02: 30:3f:62:77:88:e1:94:82:64:51:e7:1d:9b:e6:8c:b9:19:51: a7:98:5c:f3:4c:ea:6e:6c:c4:43:af:22:82:26:7b:07:6a:f7: 7b:bf:d6:8c:30:b9:31:cc:4f:ba:d0:04:e9 Once the vertification certificate is generated, it can be uploaded to AWS IoT, the process is explained in the next section. s 12 <Revision 1.2>

13 2.3.2 Upload and Activate the Self-Signed CA Certificate in AWS IoT In the AWS IoT console, go to Create a certificate > Use my certificate > Get started > Select a CA > Register CA. Upload the CA and verification certificate to AWS and activate them, as shown in Figure 3 and Figure 4. Figure 3 Register a CA certificate s 13 <Revision 1.2>

14 Figure 4 Uploading the CA certificate and verification certificate Once the CA certificate has been accepted by AWS IoT, it will be added to the certificate authorities. s 14 <Revision 1.2>

15 2.4 Registering CA Certificate using AWS Command Line Interface (CLI) Please refer to AWS documentation for installation and configuration instructions on how to use the AWS Command Line Interface (CLI). The documentation can be found online: In order to register a self-signed CA certificate with AWS IoT, it is necessary to obtain a registration code from AWS IoT. This code will be used as the Common Name field of the private key verification certificate Get the CA Registration Code After logging into AWS CLI, the CA registration code can be obtained using the following command: $ aws iot get-registration-code After getting the registration code, refer to Section where the registration code is used for CSR and CA certificate generation Upload and Activate the CA Certificate The CSR and CA certificate can be uploaded and activated using the following commands. For details and explaination of the CLI command please refer to the AWS documentation. $ aws iot register-ca-certificate --ca-certificate file://rootca.pem --verification-cert file://verificationcert.pem Example: $ aws iot register-ca-certificate --ca-certificate file://ca.cert.pem --verification-cert file://aws-reg-code.cert.pem { "certificatearn": "arn:aws:iot:us-west- 2: :cacert/0a2d0d0b03a48be41c761029add6a9e22bc46c250e81c9a7fabf06f8ab6ccf47", "certificateid": "0a2d0d0b03a48be41c761029add6a9e22bc46c250e81c9a7fabf06f8ab6ccf47" } Use the update-certificate CLI command to activate the CA certificate: $ aws iot update-ca-certificate --certificate-id xxxxxxxxxxx --new-status ACTIVE s 15 <Revision 1.2>

16 3 AWS IoT MQTT Client Configuration This shows how the MQTT Client from the Python-based AWS IoT SDK running on Raspberry Pi 3 connects to AWS IoT. Before the MQTT client can be connected to AWS IoT, the device certificate must be created to be accessible to the MQTT client. For best in class security, the Trust X is used to sign the certificate singing request (CSR) that is used to obtain the IoT device certificate from the CA. 3.1 Hardware Setup Use the raspi-config command to enable the I2C interface on Raspberry Pi, as depicted in Figure 5. Figure 5 Enabling I2C on the Raspberry Pi using raspi-config Connect a Trust X to the Raspberry Pi I2C bus as described in Chapter Install Trust X OpenSSL Engine The Trust X OpenSSL engine has a dependency on the Wiring Pi library that is required for I2C communication. Install the Wiring Pi library using the following commands: $ sudo apt-get install git-core $ sudo $HOME/trustx-aws-appnote $ mkdir misc $ cd misc $ git clone git://git.drogon.net/wiringpi $ cd wiringpi $./build s 16 <Revision 1.2>

17 Check that Wiring Pi was installed succefully: $ gpio -v gpio version: 2.44 Copyright (c) Gordon Henderson This is free software with ABSOLUTELY NO WARRANTY. For details type: gpio -warranty Raspberry Pi Details: Type: Pi 3, Revision: 02, Memory: 1024MB, Maker: Sony * Device tree is enabled. *--> Raspberry Pi 3 Model B Rev 1.2 * This Raspberry Pi supports user-level GPIO access. The Trust X OpenSSL Engine also requires OpenSSL and libssl to be installed on the system. These software packages should be installed using the following commands: $ sudo apt-get install libssl-dev $ sudo apt-get install python3-openssl The OpenSSL Trust X Engine is provided as source code only and needs to be compiled. Therefore, from the Makefile location of the Trust OpenSSL Engine, run the following command to compile and install the engine: $ cd $HOME/trustx-aws-appnote/Resources/Sources/trustx-openssl-engine_rpi-i2c $ make clean $ sudo make install Once the compilation completes without error, the Trust X OpenSSL Engine is generated as a shared object library: optiga_trustx_ex_rpi-i2c.so. A logical link will be created at /usr/lib/arm-linux-gnueabihf/engines- 1.1/optiga_trust_ex_rpi_i2c.so by the Makefile. The following command can be used to verify if the OpenSSL Trust X Engine is successfully installed on to the system. $ openssl engine optiga_trust_ex_rpi_i2c (optiga_trust_ex_rpi_i2c) Infineon OPTIGA(TM) Trust E/X engine (RPi/I2C) s 17 <Revision 1.2>

18 3.3 Create the Thing Certificate Using Trust X The following script creates a certificate signing request (CSR) using OpenSSL Trust X Engine. The CSR with Trust X public key information is signed using the private key stored in the Trust X. In our example we have used the common name TrustX (in the real world scenario this Common Name should be a uniqie Coprocessor ID of the Trust X chip). $ cd $HOME/trustx-aws-appnote/Resources/Scripts $./create-trustx-csr.sh TrustX Sample Output: $./create-trustx-csr.sh TrustX engine "optiga_trust_ex_rpi_i2c" set. 0:d=0 hl=3 l= 203 cons: SEQUENCE 3:d=1 hl=2 l= 115 cons: SEQUENCE 5:d=2 hl=2 l= 1 prim: INTEGER :00 8:d=2 hl=2 l= 17 cons: SEQUENCE 10:d=3 hl=2 l= 15 cons: SET 12:d=4 hl=2 l= 13 cons: SEQUENCE 14:d=5 hl=2 l= 3 prim: OBJECT :commonname 19:d=5 hl=2 l= 6 prim: UTF8STRING :TrustX 27:d=2 hl=2 l= 89 cons: SEQUENCE 29:d=3 hl=2 l= 19 cons: SEQUENCE 31:d=4 hl=2 l= 7 prim: OBJECT :id-ecpublickey 40:d=4 hl=2 l= 8 prim: OBJECT :prime256v1 50:d=3 hl=2 l= 66 prim: BIT STRING 118:d=2 hl=2 l= 0 cons: cont [ 0 ] 120:d=1 hl=2 l= 10 cons: SEQUENCE 122:d=2 hl=2 l= 8 prim: OBJECT :ecdsa-with-sha :d=1 hl=2 l= 72 prim: BIT STRING Using OpenSSL, generate the Trust X device certificate using the root CA certificate: $ openssl ca -config $HOME/trustx-aws-appnote/Resources/Configuration/openssl.cnf -days 999 -notext -md sha256 -in TrustX.csr.pem -out TrustX.1001.cert.pem Sample Output: $ openssl ca -config $HOME/trustx-aws-appnote/Resources/Configuration -days 999 -notext -md sha256 -in TrustX.csr.pem -out TrustX.1001.cert.pem Using configuration from openssl.cnf Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4096 (0x1000) Validity Not Before: Nov 29 06:35: GMT Not After : Aug 24 06:35: GMT Subject: commonname = TrustX Certificate is to be certified until Aug 24 06:35: GMT (999 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated s 18 <Revision 1.2>

19 Verify the generated device certificate with the following command. Below is the example output of an X.509 certificate for a Trust X: $ openssl x509 -in TrustX.1001.cert.pem -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 4096 (0x1000) Signature Algorithm: ecdsa-with-sha256 Issuer: C = SG, ST = Singapore, L = Singapore, O = Infineon Technologies Pte Ltd, OU = Chip Card & Security, CN = OPTIGA Trust X, address = XXXXXXXXXXXXXXXXXXXXXXX Validity Not Before: Nov 29 06:35: GMT Not After : Aug 24 06:35: GMT Subject: CN = TrustX Subject Public Key Info: Public Key Algorithm: id-ecpublickey Public-Key: (256 bit) pub: 04:a0:28:0e:73:9f:32:7a:8e:81:3b:5a:15:45:56: 64:97:43:dc:22:a6:03:63:84:6d:08:72:dd:bd:38: 8b:7c:c2:aa:62:25:13:0f:0f:0f:d5:73:d6:5b:fe: 07:66:77:0f:a3:a9:c6:31:5d:80:d3:76:14:32:15: 67:6b:6c:18:61 ASN1 OID: prime256v1 NIST CURVE: P-256 Signature Algorithm: ecdsa-with-sha256 30:64:02:30:04:b0:30:0f:aa:b3:47:71:c4:f2:2d:4e:27:ec: 6a:32:16:e1:64:0c:cf:c9:19:1f:86:5c:a9:17:a6:1f:2d:06: 01:b8:be:9b:4a:91:0e:e9:8b:40:23:67:c6:1d:74:aa:02:30: 50:fd:d8:76:b2:61:ba:e1:c6:2f:d3:44:d0:02:1a:13:a7:a2: 26:ba:29:6d:db:dd:8a:52:c6:37:e4:ae:0a:97:41:4a:d8:75: be:e0:2d:7e:d2:d5:0a:f8:f9:da:a4:2a Copy the certificate to the aws-node_py directory: $ cp /home/pi/trustx-aws-appnote/resources/scripts/trustx.1001.cert.pem /home/pi/trustx-aws-appnote/resources/sources/aws-node_py/credentials s 19 <Revision 1.2>

20 3.4 Create an AWS IoT Thing Using the device certificate issued by our CA, it is needs to be registered with AWS IoT. This means that a Thing needs to be created on AWS IoT, and the certificate needs to be linked to that Thing and certificate needs to have an accompany policy. A Thing can be created by launching Create from Manage >Things. The Things page shows all the existing Things on the current AWS account. Note: AWS offers its services based on several regional accounts. Therefore, a Thing created in a specific region account is not visible to other regions. For example, when a Thing is created in N. Virgina, it will not be able to see a policy in Oregon. Therefore, it is important to perform the operation on the same region account. Figure 6 Manage the Things For detailed information on device registering, please refer to the AWS documentation: Figure 7 Create a new Thing s 20 <Revision 1.2>

21 3.5 Create an AWS IoT policy Navigate to the Secure > Policies section, which shows the existing policies available in the AWS IoT account. Figure 8 Create a new Policy Create a new policy, by using the top right Create button to launch the policy creation page. A policy is a set of rules that specify AWS IoT behavior. In the Create a policy page, populate the policy name, action and resource available to that policy. For details on creating IoT policies, please refer to Figure 9 Define the Policy s 21 <Revision 1.2>

22 In this application note, the policy used allows full access to all the services. However, for secure access, resources should be restricted according to need-to-access-basis. Refer to AWS documentation for managing AWS IoT policy authorization. For details on policy authorization, please refer to Example policy used in this application note (in advanced mode). { } "Version": " ", "Statement": [ { "Effect": "Allow", "Action": "iot:*", "Resource": "*" } ] 3.6 Upload the Thing certificate to AWS IoT The left column of the AWS IoT console consists of the control panel of the IoT cloud service. By default, the main control will be the Monitor page which allows the administrator to have an overview of MQTT activities within a specific time period. If necessary, the time period can be changed with the top right drop-down button. Figure 10 AWS IoT Console In order to enable secure connection, the Thing must have a Certificate stored in the AWS IoT. Using the control panel, navigate to Secure > Certificates. If there are existing certificates, they are listed. Otherwise, use the top right Create button to register a new certificate to the AWS IoT Console. s 22 <Revision 1.2>

23 Figure 11 Certificate management Note, that in this sample application the Use my certificate option is required. If there is no CA certificate registered with AWS IoT, please refer to Chapter 2 for CA certificate registration before performing the following steps. Figure 12 Create a device certificate s 23 <Revision 1.2>

24 Select or search for the appropriate CA certificate and select Register certificates: Figure 13 1 Selection of a CA Certificate In the Register existing device certificates section, the device certificate is to be uploaded to AWS IoT. If this is missing, please refer to Chapter 2 for device certificate generation before proceeding further. Figure 14 Register device certificate in AWS IoT s 24 <Revision 1.2>

25 Once the certificate has been uploaded to AWS IoT console, it is important to check that certificate has an active status. Figure 15 Uploading the device certificate Figure 16 Successfully registered certificates in AWS IoT Review that the uploaded certificate has an active status. It is important to attach a valid policy to the certificate. The policy can be attached the device certificate. s 25 <Revision 1.2>

26 Figure 17 Attach the certificate to a Thing Figure 18 Attach a policy to the Thing s 26 <Revision 1.2>

27 4 Testing the AWS IoT MQTT Connectivity In this, the Subscribe and Publish example from the AWS IoT Python SDK is used as an example to show the cloud connectivity, data upload and download. Several configuration steps are required before the connection can be established. The AWS IoT client will require 2 digital certificates as credential for TLS mutual authentication: 1. AWS IoT Verisign Root CA (needed to verify the authenticity of the AWS endpoint) 2. X.509 certificate corresponding to the private key inside Trust X Figure 19 Get the AWS IoT endpoint address In the Python file, Resources\Sources\aws-node_py\node.py, locate the following code section to configure the appropriate AWS IoT connection parameters. In the sample application resources, all the certificates are located in the Resource\Sources\credentials\ folder. $ cd $HOME/trustx-aws-appnote/Resources/Sources/aws-node_py/ $ vi node.py # Programmatic definitions instead of read in command-line parameters host = " <Your endpoint value, see Figure 19>" rootcapath = "credentials/verisign.ca.cert.pem" certificatepath = "credentials/trustx.1001.cert.pem" privatekeypath = "ENGINE" s 27 <Revision 1.2>

28 After making the appropriate changes to the AWS IoT configuration, the MQTT client can be launched by executing the Python script node.py. The python script will initiate the TLS handshake, which includes the mutual authentication procedure. Once both the server and client have been authenticated, the sample script will execute the MQTT publish and subscribe operations to a common topic. The topic used in the example is /pythonsdk/mqtt-msg with a toggling message value of on and off. Execute the script: $ python3 node.py Sample SDK Execution output: :17:06,341 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - MqttCore initialized :17:06,342 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Client id: some_client_id :17:06,343 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Protocol version: MQTTv :17:06,343 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Authentication type: TLSv1.2 certificate based Mutual Auth :17:06,343 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring endpoint :17:06,344 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring certificates :17:06,344 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring reconnect back off timing :17:06,345 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Base quiet time: sec :17:06,345 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Max quiet time: sec :17:06,346 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Stable connection time: sec :17:06,346 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring offline requests queueing: max queue size: :17:06,348 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring offline requests queue draining interval: sec :17:06,349 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring connect/disconnect time out: sec :17:06,349 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring MQTT operation time out: sec :17:06,350 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync connect :17:06,350 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing async connect :17:06,350 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Keep-alive: sec :17:08,957 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync subscribe :17:11,238 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync publish... New message: /python-sdk/mqtt-msg: b'on' :17:21,549 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync publish... New message: /python-sdk/mqtt-msg: b'off' :17:31,849 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync publish... New message: /python-sdk/mqtt-msg: b'on' s 28 <Revision 1.2>

29 The MQTT output can be observed using the AWS IoT console. In the AWS IoT console, in the left navigation pane, choose Test. Input # on the Subscription topic to monitor all the published topics and click on Subscribe to topic. Figure 20 Use the AWS IoT MQTT Client for testing the connectivity If the connection to AWS does not work make sure your internet connection is not blocking the data traffic. You can try to tether the internet connection from your smartphone to your Raspberry PI to access AWS. s 29 <Revision 1.2>

30 5 Troubleshooting 5.1 OpenSSL.SSL.Error: [('SSL routines', 'ssl3_read_bytes', 'sslv3 alert certificate unknown')] It is possible that after you have tried to execute the node.py python script using steps described in Section 4 you can get the mentioned error. It means that a server doesn t accept a certificate provided by the script. This may happen due to several reasons: Node.py script is misconfigured. Please revisit the script content as described in Section 4. The certificatepath parameter should lead to the certificate generated in Section 3.3 and host parameter should have a value according to your AWS Endpoint, see Figure 19 AWS IoT Console doesn t have Thing credentials. Please refer to Sections s 30 <Revision 1.2>

31 6 Conclusion Connecting IoT devices to the cloud can add a tremendous value to business scenarios. A major public cloud service provider is Amazon. With Amazon Web Services (AWS), Amazon provides an exhaustive set of tools and services. To connect IoT devices to AWS, the AWS IoT provides a managed MQTT server to exchange messages among IoT devcies and other AWS services. Security is a major requirement for IoT devices and services. Amazon offers a Transport Layer Security (TLS) based device authentication and secure communication infrastructure, but leaves the creation, storage and processing of the necessary cryptographic material to the IoT device developer. With Infineon OPTIGA Trust X, the security of AWS IoT connected devcies can be greatly enhanced. The Infineon OPTIGA Trust X provides secured generation, storage and usage of cryptographic material. This application note has explained the process to establish a public-key infrastructure (PKI) to personalize Trust X devices with AWScompatible device certificates. Furthermore, this application note has shown how to design-in a Trust X device into a Raspbery Pi to securely connect to AWS IoT. s 31 <Revision 1.2>

32 Revision History Major changes since the last revision Page or Reference Whole document Section 5 Whole document Description of change Initial version Troubleshooting Section and minor changes of the document Correct text s 32 <Revision 1.2>

33 Trademarks of Infineon Technologies AG AURIX, C166, CanPAK, CIPOS, CoolGaN, CoolMOS, CoolSET, CoolSiC, CORECONTROL, CROSSAVE, DAVE, DI-POL, DrBlade, EasyPIM, EconoBRIDGE, EconoDUAL, EconoPACK, EconoPIM, EiceDRIVER, eupec, FCOS, HITFET, HybridPACK, Infineon, ISOFACE, IsoPACK, i-wafer, MIPAQ, ModSTACK, my-d, NovalithIC, OmniTune, OPTIGA, OptiMOS, ORIGA, POWERCODE, PRIMARION, PrimePACK, PrimeSTACK, PROFET, PRO-SIL, RASIC, REAL3, ReverSave, SatRIC, SIEGET, SIPMOS, SmartLEWIS, SOLID FLASH, SPOC, TEMPFET, thinq!, TRENCHSTOP, TriCore. Trademarks updated August 2015 Other Trademarks All referenced product or service names and trademarks are the property of their respective owners. Edition Published by Infineon Technologies AG München, Germany 2018 Infineon Technologies AG. All Rights Reserved. Do you have a question about this document? erratum@infineon.com Document reference ifx1 IMPORTANT NOTICE The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics ( Beschaffenheitsgarantie ). With respect to any examples, hints or any typical values stated herein and/or any information regarding the application of the product, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation warranties of non-infringement of intellectual property rights of any third party. In addition, any information given in this document is subject to customer s compliance with its obligations stated in this document and any applicable legal requirements, norms and standards concerning customer s products and any use of the product of Infineon Technologies in customer s applications. The data contained in this document is exclusively intended for technically trained staff. It is the responsibility of customer s technical departments to evaluate the suitability of the product for the intended application and the completeness of the product information given in this document with respect to such application. For further information on the product, technology, delivery terms and conditions and prices please contact your nearest Infineon Technologies office ( WARNINGS Due to technical requirements products may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies office. Except as otherwise explicitly approved by Infineon Technologies in a written document signed by authorized representatives of Infineon Technologies, Infineon Technologies products may not be used in any applications where a failure of the product or any consequences of the use thereof can reasonably be expected to result in personal injury.