Wiznet makers

w5500-tls: TLS v1.3 Client for Wiznet W5500

The W5500-tls project introduces a TLS v1.3 client specifically designed for the Wiznet W5500 SPI internet offload chip. This solution encapsulates the complexities of establishing secure connections over the internet for devices utilizing the W5500 chip. Here's an organized summary and analysis of the project:

Project Overview

• Purpose: Implements TLS v1.3 on the W5500 chip to enable encrypted communication.
• Memory Requirements: Approximately 19k of flash is needed for a thumbv7em-none-eabi target with optimizations (-O3), debug assertions enabled, and the p256-cm4 feature. Enabling full logging escalates the flash requirement by about 40k.

Current State

• Development Stage: Early alpha, indicating the project is in its preliminary phases and may contain significant bugs or incomplete features.
• Warnings and Disclaimers:
  • The project carries typical security disclaimers: it should not be used in production environments, and users should heed the potential for unconventional risks (e.g., "your hamster may explode").
  • Vulnerable to side-channel attacks, highlighting a lack of security in environments where physical access to the SPI bus or device registers is possible.
  • Utilizes a "hacky" AES implementation for in-place encryption in socket buffers, which lacks constant-time evaluation—this could lead to potential timing attacks.

Limitations

• Key Management: Currently, only supports pre-shared keys, limiting its applicability in scenarios that require more dynamic cryptographic solutions, such as those commonly used in HTTPS.
• Buffer Requirements: Requires a local buffer equivalent to the socket buffer size, which may increase memory use.
• TLS Record Management: TLS record fragmentation makes it impractical to implement streaming over socket buffers, potentially affecting performance and data handling efficiency.
• Cryptography:
  • Limited to the cipher TLS_AES_128_GCM_SHA256.
  • Key exchange is restricted to secp256r1.
  • Lacks support for certificate validation, client certificates (mutual TLS), early data, and serving TLS, significantly reducing its utility for broader applications.

Feature Flags

• The project utilizes feature flags to manage optional functionalities, all of which are disabled by default to minimize footprint and complexity:
  • eh0 and eh1: Passthrough to w5500-hl.
  • defmt: Enables logging with defmt, also passed through to w5500-hl.
  • log: Activates logging with the log library.
  • p256-cm4: Utilizes p256-cm4, an implementation optimized for Cortex-M4 CPUs, enhancing performance on compatible devices.

Implications for Use

The current state of the w5500-tls project suggests it is primarily suited for experimental or development purposes, especially in environments where security can be tightly controlled and the risks of interception are minimal. Potential users should carefully evaluate the security needs of their applications against the capabilities and limitations of this TLS implementation. Given the significant restrictions, such as the lack of certificate support and vulnerability to side-channel attacks, many commercial and consumer applications may find this solution inadequate without further development and security enhancements.

Concluding Thoughts

As the project evolves, it may incorporate broader cryptographic support and enhanced security features to mitigate its current limitations. Potential users and contributors should monitor the project’s progress and contribute to its development to tailor it more closely to the needs of secure internet communications.