Crypto: PSA TLS

Requirements
Overview
Configuration options
Building and running
- Testing
Dependencies

The PSA TLS sample shows how to perform a TLS handshake and send encrypted messages in both a secure and a non-secure domain with Trusted Firmware-M.

Note

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

Requirements 

The sample supports the following development kits:

Hardware platforms	PCA	Board name	Build target
nRF9160 DK	PCA10090	nrf9160dk_nrf9160	`nrf9160dk_nrf9160_ns` `nrf9160dk_nrf9160`
nRF5340 DK	PCA10095	nrf5340dk_nrf5340	`nrf5340dk_nrf5340_cpuapp_ns` `nrf5340dk_nrf5340_cpuapp`
nRF52840 DK	PCA10056	nrf52840dk_nrf52840	`nrf52840dk_nrf52840`

When built for an _ns build target, the sample is configured to compile and run as a non-secure application. 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 in a non-secure domain

When the sample is compiled for a non-secure domain, 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, non-secure applications only support ECDSA certificates. This is automatically enforced in the configuration files for non-secure builds.

Supported cipher suites 

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

RSA is not supported in non-secure applications.
AES256 is not supported in non-secure applications running on the 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 a non-secure firmware image for the _ns build target, the sample automatically includes the Trusted Firmware-M (TF-M).

To build the sample with Visual Studio Code, follow the steps listed on the Building nRF Connect SDK application quick guide page in the nRF Connect for VS Code extension documentation. See Building and programming an application for other building and programming scenarios and Testing and debugging an application for general information about testing and debugging in the nRF Connect SDK.

Testing 

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

Start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings:
- Baud rate: 115.200
- 8 data bits
- 1 stop bit
- No parity
- HW flow control: None
Observe the logs from the application using the terminal emulator.
Start the eth_rtt_link executable as 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
```
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
```
Type Nordic Semiconductor into the openssl connection session to send Nordic Semiconductor as an encrypted message to the server.
Check that the TLS sample returns Nordic Semiconductor in the openssl session.
Check in the terminal emulator that 21 bytes were successfully received and returned.

Start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings:
- Baud rate: 115.200
- 8 data bits
- 1 stop bit
- No parity
- HW flow control: None
Observe the logs from the application using the terminal emulator.
Start the eth_rtt_link executable as 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.1
```
Use openssl to perform the client connection and handshake operation.
```
openssl s_server -accept 4243 -cipher ECDHE-ECDSA-AES128-SHA256 -cert certs/ecdsa/cert.pem -key certs/ecdsa/cert.key
```
Note

If the sample has been built with an RSA certificate, use this openssl command:
```
openssl s_server -accept 4243 -cipher AES128-SHA256 -cert certs/rsa/cert.pem -key certs/rsa/cert.key
```
For visualizing a list of the available cipher suites for openssl, use the following command:
```
openssl ciphers
```
Type Nordic Semiconductor into the openssl connection session to send the string Nordic Semiconductor as an encrypted message to the server.
Check that the TLS sample returns Nordic Semiconductor in the openssl session.
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