Synergy Software Package User's Manual
NetX Duo DTLS Session

NetX Duo DTLS Session Introduction

DTLS is closely coupled with TLS, as the underlying security mechanisms are shared between the protocols. However,TLS is designed to work over a transport layer protocol that guarantees about packet delivery and order (almost always TCP in practice) and will not function over an unreliable protocol like UDP. It is precisely because of UDP that DTLS was introduced. DTLS was designed to handle the unreliable nature of UDP and similar protocols. It does this by including ordering and reliability logic (e.g. retransmission of dropped data) similar to reliable protocols like TCP 

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

The NetX Duo DTLS Session module is based on ThreadX "NetX Duo Secure," which implements the Datagram Transport Layer Security (DTLS) protocol as described in RFCs 6347 (version 1.2). NetX Duo Secure also includes routines for basic X.509 (RFC 5280).  

 The DTLS 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. 

NetX Duo DTLS Session Module Features

  • RFC 6347 The Datagram Transport Layer Security (DTLS) Protocol version 1.2 
  • RFC 5280 X.509 PKI Certificates (v3) 
  • RFC 3268 Advanced Encryption Standard (AES) Cipher suites for Datagram Transport Layer Security (DTLS) 
  • 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 DTLS 
  • Supports DTLS extensions for the following:
    1. Secure Renegotiation Indication: This extension mitigates a Man-in-the-Middle attack vulnerability that could occur during a renegotiation handshake. 
    2. Server Name Indication:  This extension allows a DTLS Client to supply a specific DNS name to a DTLS Server, allowing the server to select the correct credentials (assumes the server has multiple identity certificates and network entry points).
    3. Signature Algorithms: This extension enables a DTLS Client to provide a list of acceptable signature and hash algorithms to a DTLS Server 
  • Supports X.509 extensions for the following:
    1. Key Usage:  Provides acceptable uses for a certificate's public key in a bitfield 
    2. 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. 
nx_secure_dtls_BD.png
NetX Duo Secure DTLS Session Module Block Diagram

NetX Duo DTLS Session Module APIs Overview

The NetX Duo DTLS Session module defines APIs for creating and setting up a DTLS 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.

Function Name Example API Call and Description
nx_secure_dtls_client_session_start nx_secure_dtls_client_session_start( NX_SECURE_DTLS_SESSION *dtls_session, NX_UDP_SOCKET *udp_socket, NXD_ADDRESS *ip_address, UINT port, UINT wait_option);
Starts DTLS client session connecting to the provided server address and port using UDP socket.
nx_secure_dtls_packet_allocate nx_secure_dtls_packet_allocate( NX_SECURE_DTLS_SESSION *session_ptr, NX_PACKET_POOL *pool_ptr, NX_PACKET **packet_ptr, ULONG wait_option);
Allocate a packet for a NetX Secure DTLS Session
nx_secure_dtls_psk_add nx_secure_dtls_psk_add(NX_SECURE_DTLS_SESSION *session_ptr, UCHAR *pre_shared_key, UINT psk_length, UCHAR *psk_identity, UINT identity_length, UCHAR *hint, UINT hint_length);
Add a Pre-Shared Key to a NetX Secure DTLS Session
nx_secure_dtls_server_create nx_secure_dtls_server_create( NX_SECURE_DTLS_SERVER *server_ptr, NX_IP *ip_ptr, UINT port, ULONG timeout, VOID *session_buffer, UINT session_buffer_size, const NX_SECURE_TLS_CRYPTO *crypto_table, VOID *crypto_metadata_buffer, ULONG crypto_metadata_size, UCHAR *packet_reassembly_buffer, UINT packet_reassembly_buffer_size, UINT (*connect_notify)( NX_SECURE_DTLS_SESSION *dtls_session, NXD_ADDRESS *ip_address, UINT port), UINT (*receive_notify)( NX_SECURE_DTLS_SESSION *dtls_session)));
Create a NetX Secure DTLS Server
nx_secure_dtls_server_delete nx_secure_dtls_server_delete(NX_SECURE_DTLS_SERVER *server_ptr);
Free up resources used by a NetX Secure DTLS Server
nx_secure_dtls_server_local_certificate_add nx_secure_dtls_server_local_certificate_add( NX_SECURE_DTLS_SERVER *server_ptr, NX_SECURE_X509_CERT *certificate, UINT cert_id);
Add a local server identity certificate to a NetX Secure DTLS Server
nx_secure_dtls_server_local_certificate_remove nx_secure_dtls_server_local_certificate_remove( NX_SECURE_DTLS_SERVER *server_ptr, UCHAR *common_name, UINT common_name_length, UINT cert_id);
Remove a local server identity certificate from a NetX Secure DTLS Server
nx_secure_dtls_server_notify_set nx_secure_dtls_server_notify_set( NX_SECURE_DTLS_SERVER *server_ptr, UINT (*disconnect_notify)( NX_SECURE_DTLS_SESSION *dtls_session), UINT (*error_notify)( NX_SECURE_DTLS_SESSION *dtls_session, UINT error_code));
Assign optional notification callback routines to a NetX Secure DTLS Server
nx_secure_dtls_server_psk_add nx_secure_dtls_server_psk_add( NX_SECURE_DTLS_SERVER *server_ptr, UCHAR *pre_shared_key, UINT psk_length, UCHAR *psk_identity, UINT identity_length, UCHAR *hint, UINT hint_length);
Add a Pre-Shared Key to a NetX Secure DTLS Server
nx_secure_dtls_server_session_send nx_secure_dtls_server_session_send( NX_SECURE_DTLS_SESSION *session_ptr, NX_PACKET *packet_ptr);
Send data over a DTLS session established with a NetX Secure DTLS Server
nx_secure_dtls_server_session_start nx_secure_dtls_server_session_start( NX_SECURE_DTLS_SESSION *session_ptr, UINT wait_option);
Start a DTLS Session from a NetX Secure DTLS Server
nx_secure_dtls_server_start nx_secure_dtls_server_start( NX_SECURE_DTLS_SERVER *server_ptr);
Start a NetX Secure DTLS Server instance listening on the configured UDP port
nx_secure_dtls_server_stop nx_secure_dtls_server_stop(NX_SECURE_DTLS_SERVER *server_ptr);
Stop an active NetX Secure DTLS Server instance
nx_secure_dtls_server_trusted_certificate_add nx_secure_dtls_server_trusted_certificate_add( NX_SECURE_DTLS_SERVER *server_ptr, NX_SECURE_X509_CERT *certificate, UINT cert_id);
Add a trusted CA certificate to a NetX Secure DTLS Server
nx_secure_dtls_server_trusted_certificate_remove nx_secure_dtls_server_trusted_certificate_remove( NX_SECURE_DTLS_SERVER *server_ptr, UCHAR *common_name, UINT common_name_length, UINT cert_id);
Remove a trusted CA certificate from a NetX Secure DTLS Server
nx_secure_dtls_server_x509_client_verify_configure nx_secure_dtls_server_x509_client_verify_configure (NX_SECURE_DTLS_SERVER *server_ptr, UINT certs_per_session, UCHAR *certs_buffer, ULONG buffer_size);
Configure a NetX Secure DTLS Server to request and verify client certificates
nx_secure_dtls_server_x509_client_verify_disable nx_secure_dtls_server_x509_client_verify_disable (NX_SECURE_DTLS_SERVER *server_ptr);
Disables client X.509 certificate verification for a NetX Secure DTLS Server
nx_secure_dtls_session_client_info_get nx_secure_dtls_session_client_info_get( NX_SECURE_DTLS_SESSION *session_ptr, NXD_ADDRESS *client_ip_address, UINT *client_port, UINT *local_port);
Get remote client information from a DTLS Server session
nx_secure_dtls_session_create nx_secure_dtls_session_create( NX_SECURE_DTLS_SESSION *dtls_session, const NX_SECURE_TLS_CRYPTO *crypto_table, VOID *metadata_buffer, ULONG metadata_size, UCHAR *packet_reassembly_buffer, UINT packet_reassembly_buffer_size, UINT certs_number, UCHAR *remote_certificate_buffer, ULONG remote_certificate_buffer_size));
Create and configure a NetX Secure DTLS Session
nx_secure_dtls_session_delete nx_secure_dtls_session_delete( NX_SECURE_DTLS_SESSION *dtls_session);
Free up resources used by a NetX Secure DTLS Session
nx_secure_dtls_session_end nx_secure_dtls_session_end(NX_SECURE_DTLS_SESSION *dtls_session, UINT wait_option);
Shut down an active NetX Secure DTLS Session
nx_secure_dtls_session_local_certificate_add nx_secure_dtls_session_local_certificate_add( NX_SECURE_DTLS_SESSION *session_ptr, NX_SECURE_X509_CERT *certificate, UINT cert_id);
Add a local identity certificate to a NetX Secure DTLS Session
nx_secure_dtls_session_local_certificate_remove nx_secure_dtls_session_local_certificate_remove( NX_SECURE_DTLS_SESSION *session_ptr, UCHAR *common_name, UINT common_name_length, UINT cert_id);
Remove a local identity certificate from a NetX Secure DTLS Session
nx_secure_dtls_session_receive nx_secure_dtls_session_receive( NX_SECURE_DTLS_SESSION *dtls_session, NX_PACKET **packet_ptr_ptr, UINT wait_option);
Receive application data over an established NetX Secure DTLS Session
nx_secure_dtls_session_reset nx_secure_dtls_session_reset(NX_SECURE_DTLS_SESSION *dtls_session);
Clear data in an NetX Secure DTLS Session instance
nx_secure_dtls_session_send nx_secure_dtls_session_send(NX_SECURE_DTLS_SESSION *session_ptr, NX_PACKET *packet_ptr, NXD_ADDRESS *ip_address, UINT port);
Send data over a DTLS session
nx_secure_dtls_session_trusted_certificate_add nx_secure_dtls_session_trusted_certificate_add( NX_SECURE_DTLS_SESSION *session_ptr, NX_SECURE_X509_CERT *certificate, UINT cert_id);
Add a trusted CA certificate to a NetX Secure DTLS Session
nx_secure_dtls_session_trusted_certificate_remove nx_secure_dtls_session_trusted_certificate_remove( NX_SECURE_DTLS_SESSION *session_ptr, UCHAR *common_name, UINT common_name_length, UINT cert_id);
Remove a trusted CA certificate from a NetX Secure DTLS Session
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.

NetX Duo DTLS Session Status Return Values

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

NetX Duo DTLS Session Module Operational Overview

DTLS can be used in 'bare' UDP socket applications to send and receive UDP packets in a secure session to another UDP peer. 

When a secure connection is established using DTLS, 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: 

nx_secure_dtls_Prot.png
DTLS Protocol

NetX Duo DTLS Session Module Important Operational Notes and Limitations

NetX Duo DTLS Session Module Operational Notes

  • For any incoming certificate, the NetX Duo Secure DTLS will perform basic X.509 path validation. 
  • Before attempting to reconnect to the same or another DTLS server, the DTLS client must clear the DTLS session. This is most easily done by calling nx_secure_dtls_session_end.  It is recommended to delete the DTLS session and recreate it before making another connection attempt.  
  • 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. 

NetX Duo DTLS Session Module Limitations

  1. Due to the nature of embedded devices, some applications may not have the resources to support the maximum DTLS record size of 16KB. NetX Secure can handle 16KB records on devices with sufficient resources.
  2. Minimal certificate verification. NetX 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 DTLS Secure User Guide available from the Synergy Gallery for more details.
  3. Software-based cryptography is processor-intensive and is currently not supported in SSP. Therefore, hardware-based cryptography is used for optimal performance of NetX Secure DTLS.
  4. Auto initialization option for DTLS configurable properties is not supported and must be disabled.
  5. Refer to the most recent SSP release notes for additional limitations on this module.

Including the NetX Duo DTLS Session Module in an Application

This section describes how to include the NetX Duo DTLS 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 DTLS Session module to an application, simply add it to a thread using the stacks selection sequence given in the following table and enable 'DTLS' property of 'NetX Duo TLS Common' stack. 

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. 

  

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. 

nx_secure_dtls_MS.png
NetX Duo DTLS Session Module Stack

Configuring the NetX Duo DTLS Session Module

The NetX Duo DTLS 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 DTLS Session Module

ISDE Property  Value**  **Description 
Security Protocol Name  TLS, DTLS 
Default: TLS 
Security protocol selection 
Session Name  g_tls_session0  Module name 
Auto Initialization  Enable, Disable 
 
Default: Enable 
Auto initialization selection  
Meta data size 18000 Size of meta data
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.
Auto Initialization has to be disabled for DTLS Session.
The properties 'Meta data size', 'Name of Timestamp function', 'Name of Certificate Verification function', 'Name of generated initialization function' are applicable only for TLS Session.

Configuration Settings for the NetX Duo DTLS 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 
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. 
 DTLS should be enabled to use DTLS V 1.2 protocol. 
 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. 

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 DTLS 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 DTLS 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 DTLS Session Module in an Application

Note
User cannot enable Auto Initialization for DTLS session from SSP configurator. Hence the client and server initialization functions has to be invoked from the application.

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

  1. Create a DTLS session using the nx_secure_dtls_session_create 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_dtls_session_trusted_certificate_add API
  4. Start DTLS client session using nx_secure_dtls_client_session_start API.
  5. Allocate a DTLS packet to send some encrypted data to the server using nx_secure_dtls_packet_allocate API.
  6. Populate the packet with some data using nx_packet_data_appendAPI.
  7. Send data over the secure connection to the server using nx_secure_dtls_session_sendAPI.
  8. Receive data over the secure connection using nx_secure_dtls_session_receive API from the server.
  9. End the session using nx_secure_dtls_session_endAPI.

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

nx_secure_dtls_TA1.png
Flow Diagram of a Typical NetX Secure DTLS Session Module Client Application

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

  1. Create a DTLS server instance using nx_secure_dtls_server_create API. User has to define Connect and Receive Notify callback functions which will be passed as parameters to nx_secure_dtls_server_create API.
  2. Initialize local server identity certificate with key and add to server using nx_secure_x509_certificate_initialize API.
  3. Add local server identity certificate to DTLS server using nx_secure_dtls_server_local_certificate_addAPI. API.
  4. Start DTLS server using nx_secure_dtls_server_startAPI.
  5. If there is a connection attempt from the client, start DTLS server session using nx_secure_dtls_server_session_startAPI.
  6. Receive the data from connected client using nx_secure_dtls_session_receiveAPI.
  7. Send the response to client using nx_secure_dtls_server_session_sendAPI
  8. Once server processing is done, stop server instance from accepting connection requests using nx_secure_dtls_server_stopAPI.
  9. Delete DTLS server session using nx_secure_dtls_server_deleteAPI.

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

nx_secure_dtls_TA2.png
Flow Diagram of a Typical NetX Secure DTLS Session Module Server Application