Crypto: PSA TLS

The PSA TLS sample shows how to perform a TLS handshake and send encrypted messages with Cortex-M Security Extensions (CMSE) enabled, in both Non-Secure Processing Environment (NSPE) and Secure Processing Environment (SPE) with Trusted Firmware-M.

Note

Datagram Transport Layer Security (DTLS) and pre-shared key (PSK) are currently not supported.

For information about CMSE and the difference between the two environments, see Processing environments.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Board target

nRF9161 DK

PCA10153

nrf9161dk

nrf9161dk/nrf9161/ns nrf9161dk/nrf9161

nRF9160 DK

PCA10090

nrf9160dk

nrf9160dk/nrf9160/ns nrf9160dk/nrf9160

nRF9151 DK

PCA10171

nrf9151dk

nrf9151dk/nrf9151/ns nrf9151dk/nrf9151

nRF54L15 PDK

PCA10156

nrf54l15pdk

nrf54l15pdk/nrf54l15/cpuapp

nRF5340 DK

PCA10095

nrf5340dk

nrf5340dk/nrf5340/cpuapp/ns nrf5340dk/nrf5340/cpuapp

nRF52840 DK

PCA10056

nrf52840dk

nrf52840dk/nrf52840

When built for a board target with the */ns variant, the sample is configured to compile and run as a non-secure application with Cortex-M Security Extensions enabled. Therefore, it automatically includes Trusted Firmware-M that prepares the required peripherals and secure services to be available for the application.

The sample requires a TAP adapter to perform the TLS handshake. This functionality is currently only supported in Linux.

Overview

The sample can act as either a network server or a network client. By default, the sample is configured to act as a server.

Configuration options

You can configure the following options to make the sample act as either a server or a client:

CONFIG_PSA_TLS_SAMPLE_TYPE_SERVER

Set to y to make the sample act as a server. When acting as a server, the sample waits for a connection from the client on port 4243. After the TCP connection is established, the sample automatically initiates the TLS handshake by waiting for the “ClientHello” message from the client.

CONFIG_PSA_TLS_SAMPLE_TYPE_CLIENT

Set to y to make the sample act as a client. When acting as a client, the sample tries to connect to the server on port 4243. After the TCP connection is established, the sample automatically initiates the TLS handshake by sending the “ClientHello” message.

After a successful TLS handshake, the client and server echo any message received over the secured connection.

Certificates

The sample supports certificates signed with either ECDSA or RSA. By default, the sample is configured to use ECDSA certificates. Set the CONFIG_PSA_TLS_CERTIFICATE_TYPE_RSA option to y to make the sample use RSA certificates.

Certificates when running with CMSE

When the sample is compiled for NSPE alongside SPE, that is with CMSE enabled, it stores its TLS certificates and keys in the TF-M Protected Storage. During the sample initialization, the certificates and keys are fetched from TF-M Protected Storage and kept in non-secure RAM for use during every subsequent TLS handshake.

Note

Currently, applications with CMSE enabled only support ECDSA certificates. This is automatically enforced in the configuration files for board targets with CMSE enabled (*/ns variant).

Supported cipher suites

The sample supports most TLS v1.2 cipher suites, except for the following combinations:

  • RSA is not supported in applications with CMSE enabled.

  • AES256 is not supported in applications with CMSE enabled that are running on nRF9160.

TAP adapter

The sample uses the Ethernet over RTT driver library in nRF Connect SDK to transfer Ethernet frames to the connected PC. The PC must parse the incoming RTT data and dispatch these packets to a running TAP network device. This functionality is called TAP adapter.

In Linux

The TAP adapter functionality for Linux is included in the Ethernet over RTT for Linux executable, named eth_rtt_link, located in the samples/crypto/psa_tls folder. You must pass the development kit’s SEGGER ID and the TAP IPv4 as parameters when calling the executable. See the examples in the Testing section.

When using an nRF5340 development kit, if eth_rtt_link cannot start the RTT connection, pass the _SEGGER_RTT RAM block address as a parameter using --rttcbaddr, as shown in the following example:

sudo ./eth_rtt_link --snr 960010000 --ipv4 192.0.2.2 --rttcbaddr 0x20002000

You can find the _SEGGER_RTT RAM address in the .map file.

In Windows

There is currently no direct support for TAP adapters in Windows. However, you can still follow the steps given in the Testing section using a Linux distribution running inside a virtual machine.

Openssl

Use the openssl command-line interface to perform the peer network operations when testing this sample.

It can act as either client or server with simple commands in a terminal. For more information, see the Testing section.

Building and running

This sample can be found under samples/crypto/psa_tls in the nRF Connect SDK folder structure.

When built as firmware image for a board target with the */ns variant, the sample has Cortex-M Security Extensions (CMSE) enabled and separates the firmware between Non-Secure Processing Environment (NSPE) and Secure Processing Environment (SPE). Because of this, it automatically includes the Trusted Firmware-M (TF-M). To read more about CMSE, see Processing environments.

To build the sample, follow the instructions in Configuring and building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

Testing

After programming the sample to your development kit, complete the following steps to test it:

  1. Start a terminal emulator like nRF Connect Serial Terminal and connect to the used serial port with the standard UART settings. See Testing and optimization for more information.

  2. Observe the logs from the application using the terminal emulator.

  3. Start the eth_rtt_link executable as a superuser with your development kit’s SEGGER ID and the following IPv4 address as parameters:

    sudo ./eth_rtt_link --snr 960010000 --ipv4 192.0.2.2
    
  4. Use openssl to perform the client connection and handshake operation.

    openssl s_client -connect 192.0.2.1:4243 -cipher ECDHE-ECDSA-AES128-SHA256 -CAfile certs/ecdsa/root_cert.pem
    

    Note

    If the sample has been built with an RSA certificate, use this openssl command:

    openssl s_client -connect 192.0.2.1:4243 -cipher AES128-SHA256 -CAfile certs/rsa/root_cert.pem
    

    For visualizing a list of the available cipher suites for openssl, use the following command:

    openssl ciphers
    
  5. Type Nordic Semiconductor into the openssl connection session to send Nordic Semiconductor as an encrypted message to the server.

  6. Check that the TLS sample returns Nordic Semiconductor in the openssl session.

  7. Check in the terminal emulator that 21 bytes were successfully received and returned.

Dependencies

This sample uses the following Zephyr libraries:

  • Logging:

    • include/logging/log.h

  • BSD Sockets:

    • net/socket.h

  • net/net_core.h

  • net/tls_credentials.h

It also uses the following TF-M libraries:

  • tfm_ns_interface.h

  • psa/storage_common.h

  • psa/protected_storage.h