Wiznet makers

Introduction

 In an era where embedded devices are becoming increasingly interconnected, a core contradiction is becoming more prominent: on one hand, there are escalating security threats such as device hijacking and data breaches; on the other hand, there is the objective reality of limited embedded hardware resources. This contradiction often causes the TLS protocol, which should be the cornerstone of security, to encounter difficulties in software implementation—high CPU and memory overhead, stringent real-time requirements, and complex integration processes all challenge the achievement of security goals. Addressing this tension between resources and security is the starting point for building the next generation of trusted embedded systems.

WIZnet's W55MH32 MCU chip, through its innovative architecture of "hardware encryption unit + full hardware TCP/IP protocol stack," provides a more efficient security solution for embedded Ethernet communication. This solution builds an end-to-end secure communication link from the underlying hardware to the upper-layer application to address the challenges of implementing TLS encryption in embedded devices.

1. Pain Points in TLS Encryption Applications in Embedded Ethernet

1.1 Insufficient Hardware Resources, Unable to Support Standard TLS Protocol Stack

Embedded devices generally suffer from hardware limitations such as weak computing power and limited memory: most MCUs have low clock speeds, and RAM and Flash storage capacity are relatively tight. The handshake process of the standard TLS protocol involves computationally intensive processes such as asymmetric encryption, random number generation, and certificate verification. A complete two-way authentication handshake process requires a considerable amount of dynamic memory, often exceeding the hardware capacity of most devices, easily leading to decreased system stability or increased response latency.

[Image caption: Resource Comparison Chart between W55MH32 Series Chips and STM32F103 Series]

1.2 Low Software Encryption Efficiency and Difficulty in Balancing Security and Performance

When implementing TLS encryption in an embedded environment, developers need to manually disassemble complex state machines such as TCP/IP and TLS handshakes and embed them into the main loop. This presents three major technical challenges: first, the rigid nature of static memory allocation mechanisms easily leads to memory conflict risks; second, the inherent blocking nature of encryption operations directly results in a decrease in system real-time performance; and third, protocol-layer issues are highly concealed, making location and troubleshooting extremely difficult. This scenario places comprehensive and high demands on developers' understanding of underlying protocols, memory management, real-time system optimization, and problem debugging capabilities. It not only significantly raises the technical entry barrier but also greatly increases the potential risks of project delays and functional defects, posing a severe challenge to the implementation of embedded TLS.

1.3 Complex Protocol Adaptation and High Development Threshold

The core of implementing embedded Ethernet TLS encryption lies in achieving deep multi-layered adaptation between the TLS protocol stack and the TCP/IP protocol stack, hardware platform, and upper-layer applications. This process is characterized by high complexity and low fault tolerance, placing stringent demands on developers' technical expertise and engineering capabilities. Not only does the protocol stack selection and customization require precise adaptation to hardware resources—mainstream lightweight embedded protocol stacks (such as LwIP and mbed TLS) need to eliminate redundant functions to achieve extreme memory optimization—but core security capabilities such as authentication and data encryption must also be guaranteed. Any configuration deviation can lead to protocol failure or introduce security vulnerabilities. Furthermore, the engineering difficulty of multi-layered protocol co-adaptation is significant. TLS needs to be deeply coupled with the TCP/IP protocol stack's connection management and data transmission/reception logic. Developers must manually handle state machine switching, buffer allocation and synchronization, and resolve inter-layer timing conflicts. Taking the STM32+LwIP solution as an example, incomplete MAC layer parameter configuration can easily lead to abnormal TLS packet filtering. Troubleshooting such low-level issues requires a significant amount of time for waveform capture and protocol stack debugging, significantly increasing development costs and time.

1.4 Poor Random Number Quality, Weak Encryption Foundation

The security of the TLS protocol heavily relies on high-quality random numbers to generate unpredictable session keys and random parameters. However, embedded devices often use software random number generation schemes based on system time or simple hardware noise. These entropy sources have insufficient randomness and are easily predictable, leading to reduced security of the generated keys and potentially resulting in device control hijacking and sensitive data leakage.

2. Disruptive Advantages of the W55MH32 Single-Chip Hardware Encryption Solution

W55MH32 Series Chip Hardware Encryption Block Diagram

2.1 High-Specification Hardware Encryption Unit, Releasing CPU Computing Power

The W55MH32 integrates an independent hardware encryption algorithm unit, enabling it to complete critical TLS protocol operations without excessive main CPU involvement. Specific supported functions and their value are shown in the table below:

2.2 Ample Storage and Computing Power for Complex TLS Scenarios: 

The W55MH32 is equipped with a 32-bit ARM Cortex-M3 core (up to 216MHz), 1024KB Flash, and 96KB SRAM. It can easily support the complete TLS 1.2 protocol stack (including the mbed TLS library) and supports multiple concurrent connections, solving the core bottleneck of insufficient computing power and storage in traditional embedded devices.

2.3 Full Hardware TCP/IP Protocol Stack, Reducing Protocol Integration Difficulty The chip

 integrates a hard-wired TCP/IP Offload Engine (TOE), supporting protocols such as TCP, UDP, ICMP, IPv4, and ARP. This eliminates the need for software protocol stacks (such as LwIP), directly reducing the workload of adapting TLS protocols to the network layer. Simultaneously, the chip integrates a 10/100M Ethernet MAC and PHY, supporting automatic negotiation (full-duplex/half-duplex, 10M/100M), simplifying hardware design while ensuring network stability for TLS encrypted communication (e.g., in industrial environments with Ethernet link jitter, the hardware protocol stack's retransmission mechanism is more reliable).

2.4 Abundant peripheral interfaces, compatible with multiple application scenarios. 

The W55MH32 provides 66 (W55MH32L) / 36 (W55MH32Q) multi-functional GPIOs, 3 12-bit ADCs, 2 12-bit DACs, 5 UARTs, 2 SPIs, 1 CAN, and other peripherals. It can directly connect to devices such as sensors, actuators, and touch screens, and realize an end-to-end solution of "data acquisition - secure transmission - device control" without the need for additional expansion chips, reducing hardware costs and design complexity.

Device Function Configuration Table

3. W55MH32 TLS Interaction Process

3.1 TLS Handshake and Key Exchange

The W55MH32, through its built-in hardware security module, fully utilizes the chip's hardware resources to efficiently complete the TLS 1.2 handshake process and establish a secure communication session. The entire process can be divided into two main phases: secure channel establishment (handshake) and encrypted data transmission. The hardware encryption module (TRNG, SHA, AES) plays a crucial role in accelerating and enhancing security at key stages.

Phase 1: Secure Handshake and Key Negotiation

The goal of this phase is to complete identity authentication (optional) and negotiate the shared key required for this session.

Initial Negotiation (Client Hello & Server Hello)

The client sends a "Client Hello" message, which includes:

• Sending a list of supported TLS versions and cipher suites
• Providing a 32-byte high-quality client random number generated by the W55MH32 TRNG.

The server sends a "Server Hello" message, which includes:

• Selecting a TLS version and cipher suite supported by both parties (e.g., TLS_DHE_RSA_WITH_AES_256_GCM_SHA384);
• Returning a random number and digital certificate from the server;
• If DHE key exchange is used, including the server's temporary DH public key.

Authentication and Pre-Master Key Generation

Client Authentication of Server:

• Using W55MH32 SHA hardware to verify the digital signature of the server certificate, confirming the authenticity of the identity.

Generate Pre-Master Key:

DHE (Forward Security) Method:

• The client uses TRNG to generate a temporary DH private key, calculates and sends the corresponding public key.
• Both parties calculate the same pre-master key based on the DH algorithm.

RSA Method:

• The client uses TRNG to generate a 48-byte pre-master key.
• Encrypted using the server's certificate public key, it is sent and can only be decrypted by the server.

Key Derivation and Handshake Completion

Deriving Session Key:

• Both parties use the pre-master key and two random numbers to derive the master key and the final session encryption key.
• Switching between encryption and handshake authentication: Both parties send a ChangeCipherSpec message, indicating that encryption is enabled for subsequent communication; The client sends a Finished message, the content of which is encrypted with the new session key and includes the hash value of the handshake message calculated by the W55MH32 SHA hardware; The server verifies the hash to ensure the integrity of the handshake process and the success of key negotiation.

Phase Two: Efficient Encrypted Data Transmission

After the secure channel is established, all application data is transmitted using high-strength encryption.

Encryption and Integrity Protection:

When sending data, the W55MH32 AES hardware module is used to encrypt the data;

SHA hardware, in conjunction with the session key, generates a Message Authentication Code (MAC) and appends it to the data.

Decryption and Verification:

When receiving data, the MAC is first verified using SHA hardware to ensure data integrity and authenticity;

After successful verification, the data is decrypted using AES hardware.

TLS handshake process

3.2 Core Advantages of W55MH32 Hardware Acceleration

The W55MH32 integrates TRNG, SHA, and AES modules in hardware, achieving end-to-end hardware acceleration from key generation and authentication to data encryption. While ensuring a high level of security, it significantly improves the performance and efficiency of TLS communication, making it suitable for various resource-constrained and security-critical embedded network scenarios.

4. Specific Applications of W55MH32's Secure Communication Based on TLS Encryption Protocol

The core application scenarios of the W55MH32 chip's TLS encryption capability are HTTPS and MQTTS: the former is for web services, focusing on secure access to the web interface and data transmission, laying a solid foundation for remote device management; the latter is for IoT communication, and both are built with security protection through the TLS protocol.

4.1 HTTPS Secure Web Service Applications

HTTPS is a secure transmission channel based on the HTTP protocol. Its core is the addition of a TLS encryption/authentication layer between HTTP and TCP, enabling encrypted data transmission and authentication between communicating parties, thus ensuring the security and integrity of data transmission from the ground up.

HTTPS Interaction Process

The HTTPS workflow is generally as follows:

1. Establish a TCP connection
2. Perform a TLS handshake (same as the TLS handshake process described above)
3. The TLS record protocol processes the HTTP message to obtain ciphertext, achieving secure transmission.

HTTPS communication process
 

HTTPS Application Scenarios

• Remote Monitoring of Industrial Equipment: Real-time viewing of equipment status and parameters via a secure web interface.
• Smart Home Control Panel: Secure configuration interface for home gateways, preventing unauthorized access.
• Medical Device Data Upload: Encrypted transmission of patient privacy data to a medical cloud platform.
• Remote Access to Security Systems: Secure transmission and authentication of surveillance video streams.

4.2 MQTTS IoT Secure Communication

MQTTS (MQTT Secure) is a secure enhanced version of the MQTT protocol. Its core feature is the protection of transmitted data through TLS/SSL encryption layers, making it the preferred security protocol for low-bandwidth, high-reliability communication in scenarios such as the Internet of Things (IoT) and industrial automation.

MQTTS Encrypted Communication Process

The MQTTS TLS-based handshake process is as follows:

1. Client Initiates Request: The MQTT client sends the broker server the supported TLS versions, a list of encryption algorithms, and a 32-bit Client Random number generated by TRNG.
2. Server Response: The server selects the TLS version and encryption algorithm, and returns a 32-bit Server Random number.
3. Server Sends Certificate: The server sends its own certificate (including the public key) to the client.
4. Client Verifies Certificate: The client verifies the legitimacy of the server certificate using the built-in root certificate. This process involves certificate chain verification and signature verification. The W55MH32's hardware SHA and public key algorithm accelerator can significantly improve the verification speed.
5. Key Exchange: Generate a pre-master key and send it encrypted using the server's public key (Client Key Exchange).
6. Session Key Generation: The client and server derive the same session key from parameters such as the pre-master key, client random number, and server random number using the negotiated key derivation function.
7. Switching Encryption Mode: Both parties send a "Switch Encryption Mode" message; subsequent communication uses the session key for encryption.
8. Handshake Completion: Both parties send an encrypted "Finished" message to verify the integrity of the handshake.

MQTTS Communication Flow

MQTTS Use Cases

• Industrial IoT Data Acquisition: Securely uploading production line sensor data to the cloud platform
• Smart Grid Monitoring: Encrypted transmission and remote control of power equipment status information
• Vehicle-to-Everything (V2X) Communication: Secure reporting of vehicle status data and OTA upgrades
• Agricultural IoT: Encrypted collection and analysis of farmland environmental monitoring data

5 Project Progress and Delivery Guarantee

Comprehensive Technical Support:

• Provides high-quality examples of TLS hardware encryption and its SHA (SHA-1 / SHA-256) algorithms, and AES (ECB/CBC) hardware encryption
• Professional technical team provides full-process technical support
• Complete technical documentation and design guidelines
   

Stable Supply Chain Guarantee:

• Complete documentation and stable supply
• Strict quality control system
• Timely technical updates and iteration support

W55MH32 Documentation Link: https://www.w5500.com/w55mh32.html

6 Summary

The W55MH32 series MCU chip achieves high-strength TLS through deep collaborative design of hardware encryption units and a full hardware TCP/IP protocol stack. The solution effectively resolves the core contradiction between security requirements and hardware limitations by efficiently adapting encryption capabilities to resource-constrained embedded environments. It provides end-to-end encryption protection for industrial communication, from data transmission to storage, significantly improving communication efficiency through hardware encryption technology while greatly reducing the development threshold, laying a solid technical foundation for building secure, reliable, and easy-to-use next-generation embedded IoT devices.

———————————————— Copyright Notice: This article is an original work by CSDN blogger "Playing with Ethernet," licensed under CC 4.0 BY-SA. Please include the original source link and this statement when reprinting.

Original Link: https://blog.csdn.net/2301_81684513/article/details/155495294