Guides

Configuring Edge Devices with TPM Support for Enhanced Security

Suggest Edits

Introduction to Certificate-Based Authentication with TPM 2.0

In the landscape of device security, the utilization of certificate-based authentication, particularly with technologies like mTLS (Mutual Transport Layer Security) and TPM (Trusted Platform Module) 2.0, offers significant benefits. mTLS ensures that both client and server in a communication exchange can authenticate each other, enhancing the trust and security of the interactions. TPM 2.0 further bolsters this by securely generating and storing cryptographic keys directly on the device. This combination provides a robust defense against many common security threats, including phishing, man-in-the-middle attacks, and identity theft, thereby ensuring the integrity and confidentiality of sensitive data transferred between devices.

Client Support (EdgeIQ Coda)

Certificate-based authentication (mTLS): EdgeIQ Coda version 3.2 or higher

TPM2.0 Support for storing private keys used for mTLS: EdgeIQ Coda version 3.3 or higher

Preliminary Step: Acquiring an Intermediate CA Certificate

Prior to implementing certificate-based authentication (mTLS) for your devices, it is essential to obtain an intermediate Certificate Authority (CA) certificate. Please reach out to our Customer Success team to facilitate this process. This step ensures that your device authentication setup aligns with security best practices.

Setting up EdgeIQ Coda with TPM2.0 support

This guide will walk you through setting up an edge device with TPM 2.0 support, using an AWS instance equipped with NitroTPM.

Prerequisites

Ensure your device has a built-in TPM2.0 chip, TPM 1.2 is not supported. In this example, we are using an AWS instance with NitroTPM enabled. Setting up the AWS instance itself is out of scope, but you can follow these instructions Setting up an AWS Instance with NitroTPM. This guide assumes a Debian-based Operating System (Ubuntu 22.04

Step 1: Install TPM2.0 tools

Begin by installing the necessary TPM 2.0 tools on your instance:

sudo apt-get install -y apt install tpm2-tools libtpm2-pkcs11-tools libtpm2-pkcs11-1 \
	tpm2-openssl tpm2-abrmd libtss2-tcti-tabrmd0

Step 2: Generate a TPM key

Using the owner context (-C o), generate a primary key followed by a key pair, which is then loaded into the TPM under a persistent handle (0x81000000):

export TPMHANDLE=0x81000000
tpm2_createprimary -C o -c .conf/rsapss-primary.ctx
tpm2_create -G rsa2048:rsapss:null -u .conf/rsapss-key.pub \
	-r .conf/rsapss-key.priv -C .conf/rsapss-primary.ctx
tpm2_load -C .conf/rsapss-primary.ctx -u .conf/rsapss-key.pub  \
	-r .conf/rsapss-key.priv -c .conf/rsapss-key.ctx
tpm2_evictcontrol -C o -c .conf/rsapss-key.ctx $TPMHANDLE

In this example, the rsa2048:rsapss:null scheme is utilized, which employs RSA encryption with PSS padding. This scheme is compatible with the newer TLS 1.3 protocol while maintaining backward compatibility with TLS 1.2.

The persistent handle can be chosen freely within the range of available handles, please see TPM 2.0 Reserved Handles for details.

ECDSA based schemes are supported as well, please see the appendix for details.

Step 3: Generate a CSR (Certificate Signing Request)

Generate a CSR using the TPM key. This CSR is signed by the TPM key and stored in conf/<device_unique_id>.<company_id>.devices.edgeiq.ai-rsapss.csr. It is important to specify the correct Common Name (CN) to match your devices Device Unique ID and Company ID in the format <device_unique_id>.<company_id>.devices.edgeiq.ai.

`

export EDGE_UNIQUE_ID=<device_unique_id>
export EDGE_COMPANY=<company_id>
export DNSNAME=$EDGE_UNIQUE_ID.$EDGE_COMPANY.devices.edgeiq.ai
export SAN=DNS:$DNSNAME
export CERTFILE=$DNSNAME-rsapss

cat > conf/config_openssl.conf <<EOF
[ client_reqext ]
keyUsage                = critical,digitalSignature
basicConstraints        = CA:false
extendedKeyUsage        = clientAuth
subjectKeyIdentifier    = hash
subjectAltName          = \$ENV::SAN
EOF

openssl req -provider tpm2 -provider default -propquery '?provider=tpm2' \
	-new -subj "/C=US/ST=Massachusetts/L=Boston/O=EdgeIQ/OU=Enterprise/CN=$DNSNAME" \
  -key handle:$TPMHANDLE -out conf/$CERTFILE.csr

Step 4: Sign the CSR

Sign the CSR using the intermediate CA certificate and key that have been provided to you by Customer Success.

conf/<your-company>.devices.edgeiq.ai.crtis the intermediate CA certificate issued for your organization andconf/<your-company>.devices.edgeiq.ai-key.pemis the intermediate CA private key.conf/devices.edgeiq.ai is the intermediate CA issued by EdgeIQ. 

openssl x509 -req -days 360 -in conf/$CERTFILE.csr \
	-CA conf/<your-company>.devices.edgeiq.ai.crt \
  -CAkey conf/<your-company>.devices.edgeiq.ai-key.pem \
  -CAcreateserial -out conf/$CERTFILE.crt \
  -extfile conf/config_openssl.conf -extensions client_reqext

# create a chain file with the leaf (device) certificate and all intermediate CA certs
cat conf/$CERTFILE.crt conf/<your-company>.devices.edgeiq.ai.crt conf/devices.edgeiq.ai.crt > conf/$CERTFILE-chain.crt

# validate the chain up to the intermediate CA
openssl verify -CAfile conf/<your-company>.devices.edgeiq.ai.crt \
	-CAfile conf/devices.edgeiq.ai.crt conf/$CERTFILE-chain.crt

# print certificate details
openssl x509 -text -in conf/$CERTFILE.crt

Step 5: Test the connection

Adjust the default configuration in the conf/conf.json file as follows:

{
  "mqtt": {
    "client": {
      "certificate_file_path": "conf/<device_unique_id>.<company_id>.devices.edgeiq.ai-rsapss-chain.crt",
      "private_key_file_path": "handle:0x81000000",
      "tpm_device_path": "/dev/tpmrm0"
    }
  }
}

tpm_device_path is optional and defaults to /dev/tpmrm0 using the TPM2 Access Broker & Resource Manager instead of direct hardware access to the TPM2.0 chip.

Test the connection with:

EDGE_CONF=conf/conf.json ./edge

Since EdgeIQ Coda Version 3.3, the Device Unique ID and Company ID are extracted from the certificate's Common Name (CN) field and manually set values are ignored. The expected structure of the Common Name (CN) field is as follows: <device_unique_id>.<company_id>.subdomain.domain.TLD, typically <device_unique_id>.<company_id>.devices.edgeiq.ai.

Specifying EDGE_CONF=conf/conf.json is optional, because conf/conf.json is the default path for the configuration file. It was just added for clarity.

If you like to use your own domain instead of devices.edgeiq.ai within the Common Name (CN) of the certificate, this can be set up as well. Please contact customer success for details.

In case you are using a custom domain, the Company ID must be provided to the EdgeIQ Coda client in addition to the configuration file, so the command is:

EDGE_COMPANY=<company_id> EDGE_CONF=conf/conf.json ./edge

Appendix: Configuring ECDSA-Based Keys Instead of RSAPSS

For environments that require the use of Elliptic Curve Digital Signature Algorithm (ECDSA) keys instead of RSA with Probabilistic Signature Scheme (RSA-PSS), the following changes to the setup process are necessary. ECDSA keys are known for their smaller key size and efficiency in processing, which can be advantageous for systems with limited computational resources.

Adjusting Key Generation Commands

To switch from RSAPSS to ECDSA key generation, you will need to modify the TPM key generation and loading commands accordingly. Below are the adjusted commands replacing the RSA scheme with an ECDSA scheme, specifically using the ecdsa256 key type, which is commonly used and supported by most platforms.

Step 1: Generate an ECDSA TPM Key

Replace the RSA key generation commands with the following ECDSA-specific commands:

export TPMHANDLE=0x81000000
export KEYNAME=tpm-ecdsa
tpm2_createprimary -C o -c .conf/ecdsa-primary.ctx
tpm2_create -G ecc256:ecdsa-sha256 -u .conf/$KEYNAME.pub \
	-r .conf/$KEYNAME.priv -C .conf/ecdsa-primary.ctx
tpm2_load -C .conf/ecdsa-primary.ctx -u .conf/$KEYNAME.pub  \
	-r .conf/$KEYNAME.priv -c .conf/$KEYNAME.ctx
tpm2_evictcontrol -C o -c .conf/$KEYNAME.ctx $TPMHANDLE

Step 2: Generate a CSR Using the ECDSA Key

To generate a CSR with the ECDSA key, modify the OpenSSL command as follows:

export EDGE_UNIQUE_ID=<device_unique_id>
export EDGE_COMPANY=<company_id>
export DNSNAME=$EDGE_UNIQUE_ID.$EDGE_COMPANY.devices.edgeiq.ai
export SAN=DNS:$DNSNAME
export CERTFILE=$DNSNAME-ecdsa

cat > conf/config_openssl.conf <<EOF
[ client_reqext ]
keyUsage                = critical,digitalSignature
basicConstraints        = CA:false
extendedKeyUsage        = clientAuth
subjectKeyIdentifier    = hash
subjectAltName          = \$ENV::SAN
EOF

openssl req -provider tpm2 -provider default -propquery '?provider=tpm2' \
  -new -subj "/C=US/ST=Massachusetts/L=Boston/O=EdgeIQ/OU=Enterprise/CN=$DNSNAME" \
  -key handle:$TPMHANDLE -out conf/$CERTFILE.csr

All the following steps are performed identically for RSAPSS and ECDSA keys.

Summary

Switching from RSAPSS to ECDSA involves adjustments primarily in the key generation and CSR generation steps. By following these modified instructions, you can utilize the benefits of ECDSA keys, including reduced computational overhead and potentially increased security for certain applications. This change is particularly useful in environments where performance and efficiency are critical.

Updated 8 months ago