Synergy Software Package User's Manual
NetX Duo TLS Session

NetX Duo TLS Session Introduction

The NetX Duo TLS Session Module provides a high-level API for Transport Layer Security (TLS) protocol-based clients. It uses services provided by the Synergy Crypto Engine (SCE) to carry out hardware-accelerated encryption and decryption.

The NetX Duo TLS Session module is based on ThreadX "NetX Duo Secure," which implements the Secure Socket Layer (SSL) and its replacement Transport Layer Security (TLS) protocol as described in RFCs 5246 (version 1.2) and 8446 (version 1.3). NetX Duo Secure also includes routines for basic X.509 (RFC 5280). NetX Duo Secure is intended for applications using the ThreadX RTOS.

The TLS/SSL protocol provides privacy and reliability between two communicating applications. It has the following basic properties:

  • Encryption: The messages exchanged between communicating applications are encrypted to ensure that the connection is private. Symmetric cryptography mechanism such as AES (Advanced Encryption Standard is used for data encryption.
  • Authentication: A mechanism to check the peer's identity using certificates
  • Integrity:  A mechanism to detect message tampering and forgery to ensure that connection is reliable. Message Authentication Code (MAC) such as Secure Hash Algorithm (SHA) is used to ensure message integrity

An application project that demonstrates the use of the TLS as part of an MQTT client is available on the Renesas web site. The "Synergy Enterprise Cloud Toolbox" application project and application note can be found by searching the Renesas web site for "R20AN0485."

NetX Duo TLS Session Module Features

  • RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2
  • RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 
    • Note
      TLS v1.0 and v1.1 are not supported by SSP. Users are strongly recommended to migrate their projects to TLS v1.2 or TLS v1.3 in SSP immediately.
  • RFC 5280 X.509 PKI Certificates (v3)
  • RFC 3268 Advanced Encryption Standard (AES) Cipher suites for Transport Layer Security (TLS)
  • RFC 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1
  • RFC 2104 HMAC: Keyed-Hashing for Message Authentication
  • RFC 6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
  • RFC 4279 Pre-Shared Key Cipher suites for TLS
  • Supports TLS extensions for:
    • Secure Renegotiation Indication: This extension mitigates a Man-in-the-Middle attack vulnerability that could occur during a renegotiation handshake.
    • Server Name Indication:  This extension allows a TLS Client to supply a specific DNS name to a TLS Server, allowing the server to select the correct credentials (assumes the server has multiple identity certificates and network entry points).
    • Signature Algorithms: This extension enables a TLS Client to provide a list of acceptable signature and hash algorithms to a TLS Server
  • Supports X.509 extensions for:
    • Key Usage:  Provides acceptable uses for a certificate's public key in a bitfield
    • Extended Key Usage: Provides additional acceptable uses for a certificate's public key using OIDs
  • Certificate verification: Supports SHA-1, SHA-256, SHA-384,and SHA-512 signature hashing algorithms
  • Subject Alternative Name: Provides alternative DNS names that are also represented by the certificate

nxd_tls_session_BD.png
NetX Duo TLS Session Module Block Diagram

NetX Duo TLS Session Module APIs Overview

The NetX Duo TLS Support module defines APIs for creating and setting up a TLS security session.  A complete list of the available APIs, an example API call and a short description of each can be found in the following table. 

NetX Duo TLS Session Module API Summary

Function Name Example API Call and Description
nx_secure_crypto_table_self_test nx_secure_crypto_table_self_test(const NX_SECURE_TLS_CRYPTO *crypto_table,VOID *metadata, UINT metadata_size);
Perform self-test on the crypto methods
nx_secure_module_hash_compute nx_secure_module_hash_compute(NX_CRYPTO_METHOD *hamc_ptr,UINT start_address, UINT end_address, UCHAR *key, UINT key_length,VOID *metadata, UINT metadata_size,UCHAR *output_buffer, UINT output_buffer_size, UINT *actual_size);
Computes hash value using user-supplied hash function
nx_secure_tls_active_certificate_set nx_secure_tls_active_certificate_set(NX_SECURE_TLS_SESSION *tls_session,NX_SECURE_X509_CERT *certificate);
Set the active identity certificate for a NetX Secure TLS Session
nx_secure_tls_initialize nx_secure_tls_initialize(VOID);
Initializes the NetX Secure TLS module
nx_secure_tls_remote_certificate_buffer_allocate nx_secure_tls_remote_certificate_buffer_allocate(NX_SECURE_TLS_SESSION *session_ptr,UINT certs_number, VOID *certificate_buffer,ULONG buffer_size);
Allocate space for all certificates provided by a remote TLS host
nx_secure_tls_remote_certificate_free_all nx_secure_tls_remote_certificate_free_all(NX_SECURE_TLS_SESSION *session_ptr);
Free space allocated for incoming certificates
nx_secure_tls_server_certificate_add nx_secure_tls_server_certificate_add(NX_SECURE_TLS_SESSION *session_ptr, NX_SECURE_X509_CERT *certificate, UINT cert_id);
Add a certificate specifically for TLS servers using a numeric identifier
nx_secure_tls_server_certificate_find nx_secure_tls_server_certificate_find(NX_SECURE_TLS_SESSION *session_ptr, NX_SECURE_X509_CERT **certificate, UINT cert_id);
Find a certificate using a numeric identifier
nx_secure_tls_server_certificate_remove nx_secure_tls_server_certificate_remove(NX_SECURE_TLS_SESSION *session_ptr,UINT cert_id);
Remove a local server certificate using a numeric identifier
nx_secure_tls_session_client_callback_set nx_secure_tls_session_client_callback_set(NX_SECURE_TLS_SESSION *tls_session, ULONG (*func_ptr)(NX_SECURE_TLS_SESSION *tls_session, NX_SECURE_TLS_HELLO_EXTENSION *extensions, UINT num_extensions));
Set up a callback for TLS to invoke at the beginning of a TLS Client handshake
nx_secure_tls_session_x509_client_verify_configure nx_secure_tls_session_x509_client_verify_configure(NX_SECURE_TLS_SESSION *session_ptr,UINT certs_number, VOID *certificate_buffer,ULONG buffer_size);
Enable client X.509 verification and allocate space for client certificates
nx_secure_tls_session_renegotiate_callback_set nx_secure_tls_session_renegotiate_callback_set(NX_SECURE_TLS_SESSION *tls_session, ULONG (*func_ptr)(struct NX_SECURE_TLS_SESSION_struct *session));
Assign a callback that will be invoked at the beginning of a session renegotiation
nx_secure_tls_session_renegotiate nx_secure_tls_session_renegotiate(NX_SECURE_TLS_SESSION *tls_session, UINT wait_option)
Initiate a session renegotiation handshake with the remote host
nx_secure_tls_session_server_callback_set nx_secure_tls_session_server_callback_set(NX_SECURE_TLS_SESSION *tls_session, ULONG (*func_ptr)(NX_SECURE_TLS_SESSION *tls_session, NX_SECURE_TLS_HELLO_EXTENSION *extensions, UINT num_extensions));
Set up a callback for TLS to invoke at the beginning of a TLS Server handshake
nx_secure_tls_session_sni_extension_parse nx_secure_tls_session_sni_extension_parse(NX_SECURE_TLS_SESSION *session_ptr, NX_SECURE_TLS_HELLO_EXTENSION *extensions,UINT num_extensions, NX_SECURE_X509_DNS_NAME *dns_name);
Parse a Server Name Indication (SNI) extension received from a TLS Client
nx_secure_tls_session_sni_extension_set nx_secure_tls_session_sni_extension_set(NX_SECURE_TLS_SESSION *session_ptr, NX_SECURE_X509_DNS_NAME *dns_name);
Set a Server Name Indication (SNI) extension DNS name to send to a remote Server
nx_secure_tls_timestamp_function_set nx_secure_tls_timestamp_function_set(NX_SECURE_TLS_SESSION *session_ptr,ULONG (*time_func_ptr)(void));
Assign a timestamp function to a NetX Secure TLS Session
nx_secure_x509_dns_name_initialize nx_secure_x509_dns_name_initialize(NX_SECURE_X509_DNS_NAME*dns_name, const UCHAR *name_string, UINT length);
Initialize an X.509 DNS name structure
nx_secure_x509_extended_key_usage_extension_parse nx_secure_x509_extended_key_usage_extension_parse(NX_SECURE_X509_CERT*certificate, UINT key_usage);
Find and parse an X.509 extended key usage extension in an X.509 certificate
nx_secure_x509_extension_find nx_secure_x509_extension_find(NX_SECURE_X509_CERT*certificate, NX_SECURE_X509_EXTENSION *extension,USHORTextension_id);
Find and return an X.509 extension in an X.509 certificate
nx_secure_x509_key_usage_extension_parse nx_secure_x509_key_usage_extension_parse(NX_SECURE_X509_CERT*certificate, USHORT *bitfield);
Find and parse an X.509 Key Usage extension in an X.509 certificate
nx_secure_tls_local_certificate_add nx_secure_tls_local_certificate_add
(tls_session, certificate);
Adds an initialized certificate to a TLS session for use as a local identification certificate - the TLS Server certificate for TLS servers, and the Client certificate for TLS clients.
nx_secure_tls_local_certificate_remove nx_secure_tls_local_certificate_remove(
tls_session, common_name, common_name_length);
Removes a certificate instance from the local certificates list, keyed on the Common Name field.
nx_secure_tls_metadata_size_calculate nx_secure_tls_metadata_size_calculate( cipher_table, metadata_size);
Determines the size of the buffer needed by TLS for encryption metadata for a given ciphersuite table
nx_secure_tls_packet_allocate nx_secure_tls_packet_allocate(tls_session, pool_ptr, packet_ptr, wait_option);
Allocates a packet for a TLS application such that it allows additional room for the TLS header
nx_secure_tls_remote_ certificate_allocate nx_secure_tls_remote_certificate_allocate(  tls_session, certificate, raw_certificate_buffer, buffer_size);
Adds an uninitialized certificate instance to a TLS session for the purpose of allocating space for certificates provided by a remote host during a TLS session
nx_secure_tls_session_certificate_callback_set nx_secure_tls_session_certificate_callback_set(
tls_session, session);
Sets up a function pointer that TLS will invoke when a certificate is received from a remote host, allowing the application to perform validation checks such as certificate revocation and certificate policy enforcement
nx_secure_tls_session_create nx_secure_tls_session_create(session_ptr, cipher_table, metadata_area, metadata_size);
Initializes a TLS session control block for later use in establishing a secure TLS session over a TCP socket or other lower-level networking protocol
nx_secure_tls_session_client_verify_disable nx_secure_tls_session_client_verify_ disable( tls_session);
Disables Client Certificate Verification for a particular TLS Session which previously had it enabled.
nx_secure_tls_session_client_verify_enable nx_secure_tls_session_client_verify_enable(tls_session);
Enables Client Certificate Verification for TLS Server instances. If enabled, the TLS Server will request and verify a remote TLS Client Certificate using all available crypto signature routines.
nx_secure_tls_session_delete nx_secure_tls_session_delete(tls_session);
Deletes a TLS session object, returning any resources to the system
nx_secure_tls_session_end nx_secure_tls_session_end(tls_session, wait_option);
Ends an active TLS session by sending the TLS CloseNotify alert to the remote host, then waiting for the response CloseNotify before returning.
nx_secure_tls_session_packet_buffer_set nx_secure_tls_session_packet_buffer_set( session_ptr, buffer_ptr, buffer_size);
Sets the buffer TLS uses to reassemble incoming messages which may span multiple TCP packets.
nx_secure_tls_session_protocol_oversion_override nx_secure_tls_session_protocol_version_ override(tls_session, protocol_version);
Overrides the TLS protocol version to use for the TLS session. This allows for a different version of TLS to be utilized even if a newer version is enabled.
nx_secure_tls_session_receive nx_secure_tls_session_receive(tls_session, packet_ptr_ptr, wait_option);
Receives data from an active TLS session, handling all decryption and verification before returning the data to the caller in the supplied NX_PACKET structure
nx_secure_tls_session_reset nx_secure_tls_session_reset(session_ptr);
Resets a TLS session object, clearing out all data for initialization or re-use.
nx_secure_tls_session_send nx_secure_tls_session_send(tls_session, packet_ptr, wait_option);
Sends data using an active TLS session, handling all encryption and hashing before sending data over the established TCP socket connection
nx_secure_tls_session_start nx_secure_tls_session_start(tls_session, tcp_socket, wait_option);
Starts a TLS session given a TCP socket. The TCP connection must be established before calling this function or the TLS handshake will fail.
nx_secure_tls_session_time_function_set nx_secure_tls_session_time_function_set(
tls_session, time_func_ptr);
Sets up a function pointer that TLS will invoke when it needs to get the current time, which is used in various TLS handshake messages and for verification of certificates.
nx_secure_tls_trusted_ certificate_add nx_secure_tls_trusted_certificate_add(
tls_session, certificate);
Adds an initialized certificate to a TLS session for use as a trusted Root Certificate
nx_secure_tls_trusted_certificate_remove nx_secure_tls_trusted_certificate_remove( tls_session, common_name, common_name_length);
Removes a certificate instance from the trusted certificates store, keyed on the Common Name field.
nx_secure_tls_remote_certificate_free_all nx_secure_tls_remote_certificate_free_all(
NX_SECURE_TLS_SESSION *session_ptr);
Release certificates previously registered with the TLS session.
**nx_secure_tls_psk_add nx_secure_tls_psk_add(tls_session, pre_shared_key, psk_length, psk_identity, identity_length, hint, hint_length);
Adds a pre-shared key (PSK) to a TLS session for use with a PSK ciphersuite. The second parameter is the PSK identity used during the TLS handshake to select the proper key.
**nx_secure_tls_psk_find nx_secure_tls_psk_find(tls_session, psk_data, psk_length,psk_identity, identity_length);
Finds a pre-shared key (PSK) in a TLS session for use with a PSK ciphersuite. The PSK is found using an "identity hint" that should match a field in the PSK structure in the TLS session.
**nx_secure_tls_client_psk_set nx_secure_tls_client_psk_set(tls_session, pre_shared_key, psk_length, psk_identity, identity_length, hint, hint_length);
Sets the pre-shared key (PSK) for a TLS Client in a TLS session control block for use with a remote server that is sing a PSK ciphersuite.
nx_secure_x509_certificate_initialize nx_secure_x509_certificate_initialize(
NX_SECURE_X509_CERT *certificate_ptr,
const UCHAR *certificate_data,
USHORT certificate_data_length,
UCHAR *raw_data_buffer,
USHORT buffer_size,
const UCHAR *private_key_data,
USHORT private_key_data_length,
UINT private_key_type);
Initialize X.509 Certificate for NetX Secure TLS
nx_secure_x509_common_name_dns_check nx_secure_x509_common_name_dns_check(&certificate, dns_tld, dns_tld_length)
Check DNS name against X.509 Certificate
nx_secure_x509_crl_revocation_ check nx_secure_x509_crl_revocation_check(&crl_data, crl_length, &cert_store, &certificate)
Check X.509 Certificate against a supplied Certificate Revocation List
Note
For details on operation and definitions for the function data structures, typedefs, defines, API data, API structures, and function variables, review the associated Azure RTOS User's Manual in the References section.

** Requires that the property PSK Cipher Suite of the TLS Common component be enabled.

NetX Duo TLS Session Status Return Values

Please refer *NetX Secure TLS User Guide* section of Azure RTOS NetX Duo Documentation for details on status return values by NetX Secure TLS services and NetX secure X.509 Certificate error codes.

NetX Duo TLS Session Module Operational Overview

TLS uses TCP and provides secure communications for application layer protocols such as HTTP and MQTT.  TLS can also be used in 'bare' TCP socket applications to send and receive TCP packets in a secure session to another TCP peer.  The module guide for this project uses this simplified application of TLS to demonstrate a TLS Client TCP and TLS Server TCP sockets exchanging data to a TCP peer.

nxd_tls_session_LY.png
NetX Duo TLS Session Module TLS/SSL Layering

TLS does not have a well-known port number; instead, it uses the designated port number of the secure variant of the higher layer protocol. For example, port number 443 for secure HTTP, port number 8883 for MQTT, etc.

When a secure connection is established using TLS/SSL, for example using HTTPS, messages are exchanged between the client (which always initiates the connection) and a server. The first set of messages execute a Handshake Protocol after which the client and server can securely send/receive data bi-directionally, as shown in the following figure:

nxd_tls_session_PS.png
NetX Duo TLS Session Module TLS Protocol Sequences

NetX Duo TLS Session Module Important Operational Notes and Limitations

NetX Duo TLS Session Module Operational Notes

  • Before the TLS session is created, the metadata buffer must be allocated.  The size of meta data can be set using the properties pane. Also, the user can use NetX Duo Secure nx_secure_metadata_size_calculate API to calculate the required size of metadata buffer.  The Metadata size is specified in the "Meta data size" of the TLS session component, or in the nx_secure_tls_session_create call; the default value is 4k but to handle most servers, 8k is recommended if the memory space is available.
  • To associate a packet reassembly buffer to a TLS session, use the nx_secure_tls_session_packet_buffer_set API. The reassembly buffer is used to place the incoming TLS records which may span multiple TCP packets. If an incoming TLS record is larger than the supplied buffer, the TLS session will end with an error.  A reasonable packet buffer size is 6-8k.
  • Also, before starting a TLS client session, the application must allocate memory for processing Server certificate data in the nx_secure_tls_remote_certificate_allocate call. A reasonable size for most certificates is 2k.  The TLS client application should allow for 2-3 certificates from most servers. 
  • For any incoming certificate, the NetX Duo Secure TLS will perform basic X.509 path validation.
  • Additionally, at each stage in the verification process the expiration date of each certificate is checked against the time provided by the application timestamp function. The nx_secure_tls_session_time_function_set API is used to optionally set up a function pointer for application timestamp function that TLS will invoke when it needs to get the current time. The current time is used in some TLS handshake messages for verification of certificates. If a timestamp function is registered with the TLS session, a timestamp will be used in the generation of the Server or Client Hello, and in verifying the remote certificate. 
  • Before attempting to reconnect to the same or another TLS server, the TLS client must clear the TLS session. This is most easily done by calling nx_secure_tls_session_end.  It is recommended to delete the TLS session and recreate it before making another connection attempt.  For applications using SSP 1.3.x, the nx_secure_tls_session_create call should be preceded by a memset call on the TLS session to clear the session completely: memset(tls_session_ptr, 0, sizeof(NXD_SECURE_TLS_SESSION));
  • The user can use "Netx Duo TLS Common" module to configure Maximum RSA modulus size in bits. When user chooses Maximum RSA Modulus Size as 4096 bits then cryptographic operation for RSA such as encryption/decryption are done in software. Whereas if the user chooses Maximum RSA Modulus size as either 1024 or 2048 bits then cryptographic operations are done using Synergy Crypto Engine (SCE) hardware accelerator.
  • TLS1.3 implementation in SSP currently supports only ECC based signature and ECDH key sharing.

NetX Duo TLS Session Module Limitations

  • Due to the nature of embedded devices, some systems may not have adequate memory to support the maximum TLS record size of 16 KB. NetX Duo TLS Secure can handle 16KB records on devices with sufficient resources.
  • NetX Duo Secure performs basic certificate verification only. NetX Duo TLS Secure will perform basic X.509 chain verification on a certificate to assure that the certificate is valid and signed by a trusted Certificate Authority, and can provide the certificate Common Name for the application to compare against the Top-Level Domain Name of the remote host. However, verification of certificate extensions and other data is the responsibility of the application implementer. Refer to the Azure RTOS NetX Duo TLS Secure User Guide available from the Synergy Gallery for more details.
  • Software-based cryptography is processor-intensive and not available.  Therefore, hardware-based cryptography is used for optimal performance of NetX Duo TLS Secure.
  • Refer to the most recent SSP release notes for additional limitations on this module.

Including the NetX Duo TLS Session Module in an Application

This section describes how to include either or both the NetX Duo TLS Session module in an application using the SSP configurator.

Note
It is assumed you are familiar with creating a project, adding threads, adding a stack to a thread, and configuring a block within the stack. If you are unfamiliar with any of these items, refer to the first few chapters of the SSP User's Manual to learn how to manage each of these important steps in creating SSP-based applications.

To add the NetX Duo TLS Session module to an application, simply add it to a thread using the stacks selection sequence given in the following table.

Note
Both TLS and DTLS session modules are included through the same stack as mentioned below.

User need not enable  'DTLS' property of 'NetX Duo TLS Common' to use TLS services.

Note
 Both TLS and DTLS session modules are included through the same stack as mentioned below.  

User has to enable 'DTLS' property of 'NetX Duo TLS Common' stack to use DTLS services. 

NetX Duo TLS Session Module Selection Sequence

Resource ISDE Tab Stacks Selection Sequence
g_tls_session0NetX Duo TLS/DTLS Session Threads New Stack> X-Ware> NetX Duo> Protocols> NetX Duo TLS/DTLS Session

When the NetX Duo TLS/DTLS Session module is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description include Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.

nxd_tls_session_MS.png
NetX Duo TLS Session Module Stack

Configuring the NetX Duo TLS Session Module

The NetX Duo TLS Session module must be configured by the user for the desired operation. The SSP configuration window automatically identifies (by highlighting the block in red) any required configuration selections, such as interrupts or operating modes, which must be configured for lower-level modules for successful operation. Only properties that can be changed without causing conflicts are available for modification. Other properties are locked and not available for changes and are identified with a lock icon for the locked property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous manual approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP Configurator and are shown in the following tables for easy reference.

Note
You may want to open your ISDE, create the module and explore the property settings in parallel with looking over the following configuration table values. This helps to orient you and can be a useful hands-on approach to learning the ins and outs of developing with SSP.

Configuration Settings for the NetX Duo TLS Session Module

ISDE Property Value Description
Security Protocol Name TLS, DTLS
Default : TLS
Security protocol Selection
Session Name g_tls_session0 Module name
Meta data size 4000 Meta data size selection
Auto initialization Enable, Disable
Default : Enable
Auto initialization selection
*Name of Timestamp function tls_timestamp_callback0 Name of timestamp function
**Name of Certificate Verification function certificate_verification_callback0 Name of certificate verification function
Name of generated initialization function tls_dtls_session_init0 Name of generated initialization function
Note
The example settings and defaults are for a project using the S7G2 Synergy MCU Group. Other MCUs may have different default values and available configuration settings.

*The Time Stamp function is discussed in section 3.1; it is omitted in this module guide in the interests of simplicity but it is typically used to check the expiration date of each certificate against the time provided by the application. Not having a timestamp callback may cause interoperability problems and reduce the security of production release TLS application sessions.

**The Certificate Verification function provides the certificate being verified to the application so additional verification steps may be performed. It is set to NULL in the module guide project for the sake of simplicity but in a real TLS session it would be verification tool.

In some cases, settings other than the defaults for stack modules can be desirable. For example, it might be useful to select different addresses for the Ethernet port. The configurable properties for the lower-level stack modules are given in the following sections for completeness and as a reference. 

Note
Most of the property settings for lower-level modules are intuitive and usually can be determined by inspection of the associated properties window from the SSP configurator.

Configuration Settings for the NetX Duo TLS Session Lower-Level Modules

Only a small number of settings must be modified from the default for the IP layer and lower-level drivers as indicated via the red text in the thread stack block. Notice that some of the configuration properties must be set to a certain value for proper framework operation and are locked to prevent user modification. The following table identifies all the settings within the properties section for the module:

Configuration Settings for the NetX Duo Common Instance

ISDE Property Value Description
Name of generated initialization function nx_common_init0 Name of generated initialization function selection
Auto Initialization Enable, Disable

Default: Enable
Auto initialization selection
Note
The example settings and defaults are for a project using the S7G2 Synergy MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the NetX Duo TLS Common

ISDE Property  Value  Description 
Crypto Engine  Hardware  Crypto engine selection 
Self Signed Certificates  Enable, Disable 
 
Default: Disable 
Self signed certificates selection 
PSK Cipher Suite  Enable, Disable 
 
Default: Disable 
PSK cipher suite selection 
ECC Cipher Suite  Enable, Disable 
 
Default: Disable 
ECC cipher suite selection 
AES-GCM Data Buffer Size(Bytes)  Default: 2048  Maximum size of internal data buffer for encryption/decryption process in AES-GCM based cipher-suites.   
X509 Strict Name Compare  Enable, Disable 
 
Default: Disable 
X509 strict name compare selection 
X509 Extended Distinguished Names  Enable, Disable 
 
Default: Disable 
X509 extended distinguished names selection 
X509 Certificate Revocation List Check  Enable, Disable 
  
Default: Enable 
Revocation list check selection 
X509  Enable, Disable 
  
Default: Enable 
X509 feature selection 
AEAD Cipher  Enable, Disable 
  
Default: Disable 
AEAD cipher support selection 
AEAD Cipher Check  Enable, Disable 
  
Default: Disable 
AEAD cipher check selection for the AEAD cipher suites other than AES-CCM or AES-GCM 
Additional AEAD Cipher ID Default: NX_FALSE Name of a valid additional AEAD cipher ID selection 
SCSV Cipher suite  Enable, Disable 
  
Default: Disable 
SCSV cipher suite selection 
Maximum RSA Modulus size (bits)  1024, 2048, 3072, 4096 
 
Default: 4096 
Maximum RSA modulus size (bits) selection 
TLS v 1.3  Enable, Disable 
 
Default: Disable 
TLS v 1.3 selection 
TLS Version Downgrade  Enable, Disable 
 
Default: Enable 
TLS version downgrade selection 
DTLS  Enable, Disable 
 
Default: Disable 
DTLS enabling selection 
DTLS Cookie Length  32  DTLS cookie length selection 
DTLS Retransmit Retries  10  Number of DTLS retransmit retries 
DTLS Initial Retransmit Rate(Sec)  DTLS initial retransmit rate in seconds 
DTLS Maximum Retransmit Rate(Sec)  60  DTLS maximum retransmit rate in seconds 
Maximum PSK ID Size  Default: 20  Maximum PSK ID size selection (bytes) 
Maximum PSK Keys  Default: 5  Maximum PSK Keys selection 
Maximum Size of PSK  Default: 20  Maximum Size of PSK Selection (bytes) 
Minimum TLS X509 Certificate Size  Default: 256  Minimum TLS X509 Certificate size selection (bytes) 
Minimum TLS Message Buffer Size  Default: 4000  Minimum TLS Message Buffer Size selection (bytes) 
Size of TLS Pre-Master Secret  Default: 48  Size of TLS Pre-Master Secret selection (bytes) 
Secure Key Clear  Enable, Disable 
 
Default: Disable 
Secure key clear selection 
TLS SNI Extension  Enable, Disable 
 
Default: Enable 
Server name indication selection 
Server Mode  Enable, Disable 
 
Default: Enable 
Server mode selection 
Client Mode  Enable, Disable 
 
Default: Enable 
Client mode selection 
Client Certificate Verify  Enable, Disable 
 
Default: Disable 
Client certificate verification selection 
Name of generated initialization function  nx_secure_common_init  Name of generated initialization function selection 
Auto Initialization  Enable, Disable 
 
Default: Enable 
Auto initialization selection 
Note
The example settings and defaults are for a project using the S7G2 Synergy MCU Group. Other MCUs may have different default values and available configuration settings.
 TLS 1.2 will be enabled by default in any NetX Duo TLS applications.
The AES-GCM data Buffer size refers to the internal input/output buffer used for the data encryption/decryption process. The value provided should be greater than or equal to the application data packet size, considering the available RAM space.
The Pre-Master Secret size should be at least 66 bytes when ECC cipher suites are used.
When the AEAD cipher check is enabled, we recommend that the user provide a valid algorithm ID in the additional AEAD cipher ID field 

Configuration Settings for the NetX Duo Software Crypto

ISDE Property Value Description
Name g_crypto_generic Module name
Note
The example settings and defaults are for a project using the S7G2 Synergy MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the NetX Crypto Hardware Accelerator

ISDE Property Value Description
Name g_sf_el_nx_crypto Module name
Note
The example settings and defaults are for a project using the S7G2 Synergy MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the SCE Common Driver

ISDE Property Value Description
Name g_sce_0 Module name
Endian Flag CRYPTO_WORD_ENDIAN_BIG, CRYPTO_WORD_ENDIAN_LITTLE

Default: CRYPT_WORD_ENDIAN_BIG
Endian flag selection
Note
The example settings and defaults are for a project using the S7G2 Synergy MCU Group. Other MCUs may have different default values and available configuration settings.

NetX Duo TLS Session Module Clock Configuration

The ETHERC peripheral module uses PCLKA as its clock source. The PCLKA frequency is set using the SSP configurator clock tab prior to a build, or by using the CGC interface at run-time.

NetX Duo TLS Session Module Pin Configuration

The ETHERC peripheral module uses pins on the MCU device to communicate to external devices. I/O pins must be selected and configured by the external device as required.  The following table illustrates the method for selecting the pins within the SSP configuration window and the subsequent table illustrates an example selection for the I2C pins.

Note
The selected operation mode determines the peripheral signals available and the MCU pins required.

Pin Selection for the ETHERC Module

Resource ISDE Tab Pin selection Sequence
ETHERC Pins Select Peripherals > Connectivity:ETHERC > ETHERC1.RMII
Note
The selection sequence assumes ETHERC1 is the desired hardware target for the driver.

Pin Configuration Settings for the ETHERC1

Property Value Description
Operation Mode Disabled, Custom, RMII

Default: Disabled
Select RMII as the Operation Mode for ETHERC1
Pin Group Selection Mixed, _A only

Default: _A only
Pin group selection
REF50CK P701 REF50CK Pin
TXD0 P700 TXD0 Pin
TXD1 P406 TXD1 Pin
TXD_EN P405 TXD_EN Pin
RXD0 P702 RXD0 Pin
RXD1 P703 RXD1 Pin
RX_ER P704 RX_ER Pin
CRS_DV P705 CRS_DV Pin
MDC P403 MDC Pin
MDIO P404 MDIO Pin
Note
The example settings are for a project using the S7G2 Synergy MCU and the SK-S7G2 Kit. Other Synergy MCUs and other Synergy Kits may have different available pin configuration settings.

Using the NetX Duo TLS Session Module in an Application

Autogenerated code includes the initialization function with the name as specified in the Name of generated initialization function property, for example, tls_dlts_session_init0(). The TLS Session instance variable specified using the Name property of the TLS Session is passed as input to the initialization function and this instance variable can be passed as input to several APIs of the TLS layer. The initialization function internally calls the nx_secure_tls_session_create API to create a TLS session. Calls to the initialization function will be enabled or disabled depending on the Auto Initialization property value.

The steps in using the NetX Duo TLS Session module in a typical application are:

  1. Packet the reassembly buffer for TLS session using the nx_secure_tls_session_packet_buffer_set API
  2. Initialize the root CA certificate using the nx_secure_x509_certificate_initialize API
  3. Load the root CA certificate to a trusted store using the nx_secure_tls_trusted_certificate_add API
  4. Allocate space for certificates sent by remote server using the nx_secure_tls_remote_certificate_allocate API
  5. Start the TLS session using the nx_secure_tls_session_start API
  6. Send data over the secure connection using the nx_secure_tls_session_send API
  7. Receive data over the secure connection using the nx_secure_tls_session_receive API
  8. End the session using the nx_secure_tls_session_end API

The following figure illustrates common steps in a typical operational flow diagram:

nxd_tls_session_TA.png
Flow Diagram of a Typical NetX Duo TLS Session Module Application