Hardwired TCP/IP Chapter 31 :Implementing TLS 1.2 on the W55MH32 with Hardware Acceleration
Hardwired TCP/IP Chapter 31 :Implementing TLS 1.2 on the W55MH32 with Hardware Acceleration
Introduction
The W55MH32 is an enhanced 32-bit microcontroller designed by WIZnet with features that are ideal for secure, networked applications. It features a 216MHz processor core and a substantial 1024KB of Flash memory and 96KB of SRAM. Critically, it includes dedicated hardware for key cryptographic operations, such as a Hardware encryption algorithm unit with built-in algorithms for DES, AES, and SHA, and a True Random Number Generator (TRNG). These hardware features are essential for a high-performance and secure TLS 1.2 implementation, as they offload computationally intensive tasks from the main CPU. The W55MH32 also supports a Hardwired TCP/IP stack and 10/100M Ethernet MAC and PHY, making it a robust platform for secure internet communication.
What is TLS?
Transport Layer Security, is a cryptographic protocol designed to provide secure communication over a computer network. It ensures three key security properties:
Confidentiality: It encrypts data to prevent eavesdropping and unauthorized access.
Integrity: It uses message authentication codes (MACs) to ensure data hasn't been altered during transit.
Authenticity: It uses digital certificates and signatures to verify the identity of the server (and optionally the client).
TLS evolved from SSL (Secure Sockets Layer) and is the current standard for securing web traffic (HTTPS) and other data communications. It's a fundamental component of modern internet security.
TLS Handshake and Key Exchange
The TLS 1.2 handshake on the W55MH32 leverages the chip's hardware to establish a secure session efficiently.
Client Hello
The client sends a "Client Hello" message which includes:
Supported TLS version.
List of cipher suites and compression methods.
A 32-byte client random number. This number is generated using the W55MH32's TRNG function, which has four independent true random sources and can generate 128-bit random numbers at one time. This ensures the randomness is of the highest quality for cryptographic purposes.
Server Hello
The server sends a "Server Hello" message which includes:
The selected TLS version.
The chosen cipher suite (e.g., TLS_DHE_RSA_WITH_AES_256_GCM_SHA384) and compression method.
A 32-byte server random number.
The server's digital certificate and, if a DHE key exchange is chosen, the server's temporary DH public key.
Authentication & Key Exchange (by client)
The client receives the server's message and authenticates the server's identity.
The client's MCU uses the W55MH32's SHA from the Hardware encryption algorithm unit to verify the digital signature on the server's certificate. This confirms the certificate's authenticity and integrity.
The client then uses the server's temporary DH public key and its own private key to independently compute a pre-master secret.
Client Key Exchange
The client sends its key exchange message to the server:
DHE: temporary Public key from client The client generates its temporary DH public key using its own TRNG function and sends it to the server. The server then uses this key along with its own private key to compute the same pre-master secret.
RSA: Pre-master secret
The client generates a 48-byte pre-master secret. This is a random number created using the W55MH32's TRNG function.
The client encrypts this pre-master secret using the server's public key from the certificate.
The client sends the encrypted pre-master secret to the server. Only the server, with its matching private key, can decrypt it.
ChangeCipherSpec and Finished
This is the final verification stage of the handshake.
ChangeCipherSpec message
Finish message (Encrypted)
Finish message (Hashed)
The client and server derive the master secret and session keys from the pre-master secret and the random numbers.
Both parties send a ChangeCipherSpec message, signaling that all subsequent communication will be encrypted.
The client sends a Finished message. This message is encrypted with the new session keys and contains a hash of all previous handshake messages. The W55MH32's SHA hardware is used to compute this hash. The server decrypts it and verifies the hash to confirm a successful key exchange and that the handshake was not tampered with.
Data Communication
Encrypted Data Transfer:
Once the handshake is complete, all application data is secured using the session keys.
The application data is encrypted using the W55MH32's AES hardware block from the Hardware encryption algorithm unit.
A Message Authentication Code (MAC) is calculated using the W55MH32's SHA and the session MAC key.
The encrypted data and the MAC are sent to the other party.
The receiving party uses the W55MH32's AES hardware to decrypt the data and the W55MH32's SHA hardware to verify the MAC. A successful verification guarantees the data's integrity and authenticity.
Demo Section
A demonstration of the W55MH32's TLS 1.2 capabilities would follow these steps:
Hardware & Network Setup:Initialize the 10/100M Ethernet MAC and PHY of W55MH32 to establish a physical connection, and configure the hardware TCP/IP protocol stack for network communication.
Network configuration initialization, which includes network configuration parameters such as MAC address, IP address, gateway, subnet mask, DNS server address and DHCP mode.
/* network information */
wiz_NetInfo default_net_info = {
.mac = {0x00, 0x08, 0xdc, 0x12, 0x22, 0x12},
.ip = {10, 0, 1, 140},
.gw = {10, 0, 1, 254},
.sn = {255, 255, 255, 0},
.dns = {8, 8, 8, 8},
.dhcp = NETINFO_DHCP
};Define three variables: ethernet_buf as the buffer for network data transmission and reception, ssl_target_ip as the target IP address of the Baidu server, and tlsContext for maintaining all the status and configuration information of the TLS connection.
uint8_t ethernet_buf[ETHERNET_BUF_MAX_SIZE] = {0};
uint8_t ssl_target_ip[4] = {182, 61, 244, 181}; // baidu
wiz_tls_context tlsContext;Hardware and network settings: Initialize hardware, encryption module, TRNG, timer, initialize Wiztoe and check PHY link, finally initialize the network.
/* hardware initialization */
rcc_clk_config();
delay_init();
console_usart_init(115200);
printf("W55MH32 TLS Example\r\n");
/* hardware crypt initialization */
*(uint32_t *)(0x400210F0) = 0x01;
*(uint32_t *)(0x40016C00) = 0xCDED3526;
*(uint32_t *)(0x40016CCC) = 0x07;
/* hardware TRNG enable */
TRNG_Out(ENABLE);
tim3_init();
/* wiztoe init */
wiz_toe_init();
getSHAR(default_net_info.mac);
wiz_phy_link_check();
network_init(ethernet_buf, &default_net_info);
TLS Secure Connection Establishment Process
uint32_t ver = wiz_crypt_version();
printf("WIZnet CARD Secure Test Demo V1.0, secure lib version is V%02x.%02x.%02x.%02x\n", ver >> 24, (ver >> 16) & 0xFF, (ver >> 8) & 0xFF, ver & 0xFF);
printf("WIZnet CARD Crypt Test V1.0 start......\r\n");
/* open socket */
wiz_tls_socket(&tlsContext, SOCKET_SSL_ID, LOCAL_PORT);
/* tls init */
wiz_tls_init(&tlsContext, 2000, (char *)ssl_target_ip, NULL, NULL, NULL);
/* connect server*/
connect(tlsContext.socket_fd, (uint8_t *)ssl_target_ip, SSL_TARGET_PORT);
/* tls handshake */
wiz_tls_connect(&tlsContext, (char *)ssl_target_ip, SSL_TARGET_PORT);
printf("W55MH32 MbedTLS Transmission test start......\r\n");
TLS Initialization and Handshake Process
The wiz_tls_init function is used to initialize the TLS client connection. The parameters include: a pointer to the TLS context structure, the receive timeout time (in milliseconds), the target server domain/IP address, the root certificate string (for verifying the server identity), the client certificate string and the private key string (used for client authentication).
int wiz_tls_init(wiz_tls_context *tlsContext, uint32_t recv_timeout, char *domain_name, char *root_ca, char *client_cert, char *pkey)
{
int ret = 1;
const char *pers = "ssl_client1";
const char *alpnProtocols[] = {"x-amzn-mqtt-ca", NULL};
char error_buf[100];
mbedtls_debug_set_threshold(MBEDTLS_DEBUG_LEVEL);
/*
Initialize session data
*/
tlsContext->entropy = malloc(sizeof(mbedtls_entropy_context));
tlsContext->ctr_drbg = malloc(sizeof(mbedtls_ctr_drbg_context));
tlsContext->ssl = malloc(sizeof(mbedtls_ssl_context));
tlsContext->conf = malloc(sizeof(mbedtls_ssl_config));
tlsContext->cacert = malloc(sizeof(mbedtls_x509_crt));
tlsContext->clicert = malloc(sizeof(mbedtls_x509_crt));
tlsContext->pkey = malloc(sizeof(mbedtls_pk_context));
mbedtls_entropy_init(tlsContext->entropy);
mbedtls_ctr_drbg_init(tlsContext->ctr_drbg);
mbedtls_ssl_init(tlsContext->ssl);
mbedtls_ssl_config_init(tlsContext->conf);
mbedtls_x509_crt_init(tlsContext->cacert);
mbedtls_x509_crt_init(tlsContext->clicert);
mbedtls_pk_init(tlsContext->pkey);
const int *ciphersuite_list = mbedtls_ssl_list_ciphersuites();
while (*ciphersuite_list != 0)
{
const char *name = mbedtls_ssl_get_ciphersuite_name(*ciphersuite_list);
if (name != NULL)
printf("%s\r\n", name);
ciphersuite_list++;
}
/*
Initialize certificates
*/
if ((ret = mbedtls_ctr_drbg_seed(tlsContext->ctr_drbg, mbedtls_entropy_func, tlsContext->entropy,
(const unsigned char *)pers, strlen(pers)))
!= 0)
{
printf(" failed\r\n ! mbedtls_ctr_drbg_seed returned -0x%x\r\n", -ret);
return -1;
}
mbedtls_ssl_conf_dbg(tlsContext->conf, WIZnetDebugCB, stdout);
/*
Parse certificate
*/
if (root_ca != NULL)
{
uint16_t root_ca_len = strlen(root_ca);
printf(" Loading the CA root certificate len = %d\r\n", root_ca_len);
ret = mbedtls_x509_crt_parse(tlsContext->cacert, (const unsigned char *)root_ca, root_ca_len + 1);
if (ret < 0)
{
printf(" failed\r\n ! mbedtls_x509_crt_parse returned -0x%x while parsing root cert\r\n", -ret);
return -1;
}
printf("ok! mbedtls_x509_crt_parse returned -0x%x while parsing root cert\r\n", -ret);
uint8_t ip_temp[4];
if (!is_ipaddr((uint8_t *)domain_name, (uint8_t *)ip_temp))
{
if ((ret = mbedtls_ssl_set_hostname(tlsContext->ssl, domain_name)) != 0)
{
printf(" failed mbedtls_ssl_set_hostname returned %d\r\n", ret);
return -1;
}
}
else
{
if ((ret = mbedtls_ssl_set_hostname(tlsContext->ssl, NULL)) != 0)
{
printf(" failed mbedtls_ssl_set_hostname returned %d\r\n", ret);
return -1;
}
}
printf("ok! mbedtls_ssl_set_hostname returned %d\r\n", ret);
tlsContext->root_ca_option = MBEDTLS_SSL_VERIFY_REQUIRED;
}
else
{
tlsContext->root_ca_option = MBEDTLS_SSL_VERIFY_NONE;
}
if (client_cert != NULL && pkey != NULL)
{
uint32_t client_cert_len = strlen(client_cert);
uint32_t pkey_len = strlen(pkey);
ret = mbedtls_x509_crt_parse((tlsContext->clicert), (const unsigned char *)client_cert, client_cert_len + 1);
if (ret != 0)
{
printf(" failed\r\n ! mbedtls_x509_crt_parse returned -0x%x while parsing device cert\r\n", -ret);
return -1;
}
printf("ok! mbedtls_x509_crt_parse returned -0x%x while parsing device cert\r\n", -ret);
ret = mbedtls_pk_parse_key(tlsContext->pkey, (const unsigned char *)pkey, pkey_len + 1, NULL, 0, mbedtls_ctr_drbg_random, tlsContext->ctr_drbg);
if (ret != 0)
{
printf(" failed\r\n ! mbedtls_pk_parse_key returned -0x%x while parsing private key\r\n", -ret);
return -1;
}
printf("ok! mbedtls_pk_parse_key returned -0x%x while parsing private key\r\n", -ret);
}
if ((ret = mbedtls_ssl_config_defaults(tlsContext->conf,
MBEDTLS_SSL_IS_CLIENT,
MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT))
!= 0)
{
printf(" failed mbedtls_ssl_config_defaults returned %d\r\n", ret);
return -1;
}
printf("socket_fd = %d\r\n", tlsContext->socket_fd);
mbedtls_ssl_conf_authmode(tlsContext->conf, tlsContext->root_ca_option);
mbedtls_ssl_conf_ca_chain(tlsContext->conf, tlsContext->cacert, NULL);
mbedtls_ssl_conf_rng(tlsContext->conf, SSLRandomCB, tlsContext->ctr_drbg);
if (client_cert != NULL && pkey != NULL)
{
if ((ret = mbedtls_ssl_conf_own_cert(tlsContext->conf, tlsContext->clicert, tlsContext->pkey)) != 0)
{
printf("failed! mbedtls_ssl_conf_own_cert returned %d\r\n", ret);
return -1;
}
printf("ok! mbedtls_ssl_conf_own_cert returned %d\r\n", ret);
}
mbedtls_ssl_conf_endpoint(tlsContext->conf, MBEDTLS_SSL_IS_CLIENT);
if (recv_timeout == 0)
recv_timeout = 2000;
mbedtls_ssl_conf_read_timeout(tlsContext->conf, recv_timeout);
if ((ret = mbedtls_ssl_setup(tlsContext->ssl, tlsContext->conf)) != 0)
{
printf(" failed mbedtls_ssl_setup returned -0x%x\r\n", -ret);
return -1;
}
mbedtls_ssl_set_bio(tlsContext->ssl, (void *)tlsContext->socket_fd, SSLSendCB, SSLRecvCB, SSLRecvTimeOutCB);
printf("return 1\r\n");
return 1;
}During this testing process (with a 2-second timeout and the target server's IP set, but without configuring the certificate verification parameters).
/* tls init */
wiz_tls_init(&tlsContext, 2000, (char *)ssl_target_ip, NULL, NULL, NULL);TLS handshake process: Establish a TLS connection with the server, call the W55MH32 hardware-based TRNG to generate random numbers, and use the SHA engine to perform verification.
The TRNG_Out function enables or disables the TRNG (True Random Number Generator) module, thereby providing the necessary true random number sources for the TLS handshake process, ensuring the random entropy sources required for secure operations such as key generation in the TLS protocol.
/**
* @brief TRNG_Stop
* @param
* @retval None
*/
void TRNG_Out(FunctionalState NewState)
{
if (NewState != DISABLE)
{
RCC->RCC_SYSCFG_CONFIG = 0x01;
SYSCFG->SYSCFG_LOCK = 0xCDED3526;
SYSCFG->SSC_CLK_EN |= TRNG_RNG_ENABLE;
}
else
{
RCC->RCC_SYSCFG_CONFIG = 0x00;
SYSCFG->SSC_CLK_EN &= ~TRNG_RNG_ENABLE;
}
}
/************************** (C) COPYRIGHT 2024 WIZnet *****END OF FILE****/
The function "wiz_tls_connect" is the core function of the TLS client, its role is to perform the TLS handshake: by repeatedly calling the "mbedtls_ssl_handshake" function to handle the handshake process, when enabling certificate verification, it will verify the legitimacy of the server certificate (this test is a certificate verification-free mode), after the handshake is successful, it will output the negotiated encryption suite, and finally complete the establishment of the TLS secure connection or return an error.
int wiz_tls_connect(wiz_tls_context *tlsContext, char *addr, unsigned int port)
{
int ret;
uint32_t start_ms = millis(), flags;
printf(" Performing the SSL/TLS handshake...\r\n");
while ((ret = mbedtls_ssl_handshake(tlsContext->ssl)) != 0)
{
if (ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE)
{
//mbedtls_strerror(ret, (char *) tempBuf, DEBUG_BUFFER_SIZE );
//printf( " failed\n\r ! mbedtls_ssl_handshake returned %d: %s\n\r", ret, tempBuf );
printf(" failed\n\r ! mbedtls_ssl_handshake returned -0x%x\n\r", -ret);
return (-1);
}
delay_ms(10);
}
if (tlsContext->root_ca_option == MBEDTLS_SSL_VERIFY_REQUIRED)
{
printf(" . Verifying peer X.509 certificate...\r\n");
/* In real life, we probably want to bail out when ret != 0 */
if ((flags = mbedtls_ssl_get_verify_result(tlsContext->ssl)) != 0)
{
char vrfy_buf[512];
printf("failed\r\n");
mbedtls_x509_crt_verify_info(vrfy_buf, sizeof(vrfy_buf), " ! ", flags);
printf("%s\r\n", vrfy_buf);
return -1;
}
else
{
printf("ok\r\n");
}
}
printf(" ok\n\r [ Ciphersuite is %s ]\n\r",
mbedtls_ssl_get_ciphersuite(tlsContext->ssl));
return (0);
}
The mbedtls_ssl_handshake function is the core implementation of the SSL/TLS handshake protocol in the mbedTLS library. It completes the processes such as encryption parameter negotiation, key exchange, and authentication by repeatedly calling the handshake step functions until the handshake is completed or an error occurs. Eventually, a secure encrypted communication channel between the client and the server is established.
/*
* Perform the SSL handshake
*/
int mbedtls_ssl_handshake(mbedtls_ssl_context *ssl)
{
int ret = 0;
/* Sanity checks */
if (ssl == NULL || ssl->conf == NULL) {
return MBEDTLS_ERR_SSL_BAD_INPUT_DATA;
}
if (ssl->conf->transport == MBEDTLS_SSL_TRANSPORT_DATAGRAM &&
(ssl->f_set_timer == NULL || ssl->f_get_timer == NULL)) {
MBEDTLS_SSL_DEBUG_MSG(1, ("You must use "
"mbedtls_ssl_set_timer_cb() for DTLS"));
return MBEDTLS_ERR_SSL_BAD_INPUT_DATA;
}
/* MBEDTLS_SSL_PROTO_DTLS */
MBEDTLS_SSL_DEBUG_MSG(2, ("=> handshake"));
/* Main handshake loop */
while (ssl->state != MBEDTLS_SSL_HANDSHAKE_OVER) {
ret = mbedtls_ssl_handshake_step(ssl);
if (ret != 0) {
break;
}
}
MBEDTLS_SSL_DEBUG_MSG(2, ("<= handshake"));
return ret;
}
Secure Communication: After the handshake is completed, the application can send and receive data. The W55MH32's AES and SHA hardware is utilized to handle all encryption, decryption and integrity checks, allowing the main CPU to focus on the application logic.
After the TLS handshake is successful, all data is transmitted and received through an encrypted channel. The core of this process is to call wiz_tls_write (for encrypted sending) and wiz_tls_read (for encrypted receiving).
unsigned int wiz_tls_read(wiz_tls_context *tlsContext, unsigned char *readbuf, unsigned int len)
{
return mbedtls_ssl_read(tlsContext->ssl, readbuf, len);
}
unsigned int wiz_tls_write(wiz_tls_context *tlsContext, unsigned char *writebuf, unsigned int len)
{
return mbedtls_ssl_write(tlsContext->ssl, writebuf, len);
}
Through the established TLS secure connection, an HTTP GET request is sent to the Baidu server to obtain the web page content. In an infinite loop, the received response data from the server is continuously received and printed. This implements a simple HTTPS client function to obtain and display the HTML content of Baidu's homepage.
if (1)
{
printf("W55MH32 get baidu.com html content......\r\n");
mbedtls_ssl_conf_read_timeout(tlsContext.conf, 200);
sprintf(ethernet_buf, "GET / HTTP/1.1\r\nHost: www.baidu.com\r\nUser-Agent: W55MH32/1.0\r\nAccept: text/html\r\nConnection: close\r\n\r\n");
wiz_tls_write(&tlsContext, (unsigned char *)ethernet_buf, strlen(ethernet_buf));
while (1)
{
recv_len = wiz_tls_read(&tlsContext, ethernet_buf, ETHERNET_BUF_MAX_SIZE - 1);
if (recv_len > 0)
{
printf("recv_len:%d\r\n", recv_len);
ethernet_buf[recv_len] = '\0';
printf("Received: %s", ethernet_buf);
}
}
}
Run results
We conducted a routine test to obtain information from Baidu web pages using HTTPS. Through the serial port, we printed and displayed that the W55MH32 PHY link was normal, DHCP obtained the network successfully, and after loading the encryption library, the TLS handshake (suite TLS-RSA-WITH-AES-128-GCM-SHA256) was completed. Then, we sent the request and received the response from Baidu.
W55MH32 initiated the MbedTLS transmission test and attempted to obtain the HTML content from Baidu. It successfully received 490 bytes of data, which was the HTTP 302 temporary redirect response (including the redirection address, server information, etc.) returned by Baidu along with the corresponding HTML page.
Analysis of TLS Handshake Process Messages
Packet capture using Wireshark demonstrated the process of establishing a connection through the TCP three-way handshake, followed by the TLS handshake (including client hello, server hello, key exchange, etc.) to establish a secure communication channel and transmit application data.
We know that the HTTPS protocol is based on the TCP/IP protocol. Therefore, before the TLS handshake, the client and the Baidu server conducted three TCP handshakes respectively.
Then, you can observe the process of establishing a secure channel through the TLS handshake. In the display filter of Wireshark, enter the expression "ip.addr == 192.168.1.13 and tls" to filter out the TLS protocol data packets. W55MH32 is the client (192.168.1.13) accessing the Baidu server (182.61.244.181).
First handshake message (164): W55MH32 -> Baidu Sent TLS message 「Client Hello」；
Second handshake message (166, 176):
Baidu -> W55MH32 sent the TLS message 「Server Hello」；
Baidu -> W55MH32 sent TLS message 「Certificate」, 「Server Hello Done」；
The third handshake message (192, 193, 194): W55MH32 -> Baidu. Sent TLS messages 「Client Key Exchange」, 「Change Cipher Spec」, 「Encrypted Handshake Message」;
Fourth handshake message (200): Baidu -> W55MH32 sent TLS message 「Change Cipher Spec」, 「Encrypted Handshake Message」. The handshake process is shown in the figure below:
The first handshake of TLS: client -> server (Client Hello) The client sends to the server:
The protocols supported by the client side;
The already used TLS version;
Random number;
Supported cipher suites.
Next, let's take a look at some important fields in the TLS protocol (Version, Random, SessionID and Cipher Suites).
As can be seen from the above figure, the current communication security layer protocol version is TLS 1.2. In fact, TLS has a total of 4 versions, with the latest being TLS 1.3. The details are as follows:
- TLS 1.3: Released in 2018, TLS 1.3 is the latest version of the TLS protocol. It significantly simplifies the handshake process, enhancing performance and security. It has removed some insecure encryption algorithms and introduced the 0-RTT (zero round-trip time) handshake to reduce latency.
- TLS 1.2: TLS 1.2 was released in 2008. It introduced stronger encryption algorithms and more flexible cipher suite selection, fixed many security vulnerabilities, and is currently the widely used version. (In the current example, the Baidu website is using the TLS 1.2 protocol.)
- TLS 1.1: TLS 1.1 was released in 2006 and introduced several improvements, including enhancements to the security of the CBC (Cipher Block Chaining) mode. However, there are still some known security issues.
- TLS 1.0: TLS 1.0 was released in 1999. It is an upgraded version of SSL 3.0, which has fixed some security vulnerabilities, but still has some security issues.
Random is used for generating keys. Here, we will refer to the random number sent by the client to the server in the first handshake as "Client Random".
The SessionID is used to indicate whether the client intends to reuse an existing session. If not, this field is set to 0; if it intends to reuse, this field contains the session ID to be reused, and the decision on whether to reuse is made by the server.
The Cipher Suites list will be sent to the server in its entirety. The server will then select the most secure cipher suite from this list and return it to the client.
The format of a cipher suite typically consists of a series of encryption algorithms and related parameters. Generally speaking, its format includes the following components:
- Key exchange algorithm: Used for negotiating session keys, such as Diffie-Hellman (DHE), ECDHE, etc.
- Authentication algorithm: Also known as signature algorithm, it is used to verify the identity of the other party, such as RSA.
- Encryption algorithm: Algorithms used for encryption and decryption of actual data transmission, such as AES (Advanced Encryption Standard), RC4, etc.
- Data summary algorithm: Used for calculating hash values, mainly for verifying the integrity of data and preventing information from being tampered with.
"Key exchange algorithm + signature algorithm (authentication algorithm) + symmetric encryption algorithm + hash algorithm". Here, the key exchange algorithm and the signature algorithm can be the same, in which case they can be combined into one.
Different combinations of cipher suites offer different levels of security and performance. During the TLS handshake, the server and the client will negotiate and select the Cipher Suite that both support to establish a secure connection.
After the client sends "Client Hello", the server sends an ACK confirmation message to the client, indicating that the "Client Hello" has been received. This also shows that the server responds to "Client Hello" using the ordinary TCP ACK message.
The second handshake of TLS: server -> client (1. Server Hello; 2. Certificate, Server Key Exchange, Server Hello Done) During this handshake, the server sent two consecutive messages to the client:
- Server Hello: The server, to prove its identity, will send "Server Certificate" to the client.
- This message contains a digital certificate.
- Certificate, Server Hello Done: The purpose is to inform the client that I have given you all the things I was supposed to give you, and this greeting is complete.
- The protocols supported by the server;
- The TLS version used; Random number
- The cipher suites selected by the server.
As can be seen in the above figure, the server also generated a random number and sent it to the client. The random number generated by the server is referred to as "Server Random".
The client and the server have confirmed the TLS version and the used cipher suite as TLS_RSA_WITH_AES_128_GCM_SHA256.
The server sends the message: Certificate, Server Hello Done.
The third handshake of TLS client -> server (Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message)
The client transmits the encrypted pre-master key, modifies the password specification, and sends the encrypted handshake message to the server.
The fourth handshake of TLS server -> client (Change Cipher Spec,Encrypted Handshake Message)
The server performs the same operation as well, sending the "Change Cipher Spec" and "Encrypted Handshake Message" messages. If both parties confirm that the encryption and decryption are correct, then the TLS handshake is officially completed.
After the TLS handshake is completed, all communication content between the client and the server is encrypted. Without a session key, the communication content cannot be decrypted.
The server issued a close notification (close_notify) in accordance with the TLS protocol specifications, and immediately sent a TCP RST message to quickly release the connection resources.
Conclusion
Implementing TLS 1.2 on a constrained device like an embedded microcontroller is a challenging but necessary task for secure connectivity. By leveraging hardware acceleration features such as TRNG, SHA256, and AES256, developers can create robust and performant secure communication channels. The W55MH32's dedicated hardware for these functions, including its Hardware encryption algorithm unit and TRNG, allows the main CPU to focus on application logic, which is crucial for high-performance and secure embedded systems.