4. mbedTLS 移植与配置：裁剪编译、内存池配置、随机数生成器、硬件加速接口

好，咱们进入正题。mbedTLS 的移植，说白了就是让这个 TLS 库在你的嵌入式芯片上跑起来，而且跑得稳、跑得快、跑得省。我见过太多人直接把桌面版的配置扔到 MCU 上，结果编译都过不了，或者跑起来内存直接爆掉。嗯，这章咱们就把这些坑一个个填上。

4.1 裁剪编译：别让库比你应用还大

mbedTLS 默认配置是为通用场景准备的，功能全，但体积也大。嵌入式环境里，Flash 和 RAM 都是硬约束。我个人的习惯是，先搞清楚你的设备到底需要哪些 TLS 特性。

举个例子，如果你的设备只作为 TLS 客户端，那服务端相关的代码就可以全部砍掉。如果你只用 ECDHE 密钥交换，那 RSA 密钥交换的代码就是废的。

裁剪的核心在于 mbedtls_config.h 这个文件。你需要通过宏定义来控制哪些模块参与编译。

核心原则： 只编译你需要的。一个典型的 IoT 客户端，裁剪后 Flash 占用可以从 200KB 降到 50KB 左右。

我建议你按这个步骤来操作：

  1. 从默认配置开始：先复制一份 mbedtls_config.h 到你的项目里。
  2. 禁用不需要的协议版本：比如只保留 TLS 1.2，砍掉 TLS 1.0、1.1 和 DTLS（如果不需要）。
  3. 精简密码套件：只保留你计划使用的 2-3 个套件。比如 MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED 和 MBEDTLS_CIPHER_AES_128_GCM。
  4. 砍掉调试和测试代码：MBEDTLS_SELF_TEST、MBEDTLS_DEBUG_C 这些在发布版本里一定要关掉。
  5. 禁用文件系统接口：如果你的设备没有文件系统，把 MBEDTLS_FS_IO 关掉。

我的经验： 我曾经在一个只有 128KB Flash 的芯片上做项目。一开始没裁剪，编译出来 180KB，直接跪了。后来花了半天时间，一项一项地关，最后压到了 45KB。那种感觉，就像把一个大胖子塞进小汽车里，刚刚好。

下面是一个典型的裁剪配置片段，你可以参考：

// 在 mbedtls_config.h 中
// 只保留 TLS 1.2
#define MBEDTLS_SSL_PROTO_TLS1_2

// 只保留 ECDHE + ECDSA 密钥交换
#define MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED

// 只保留 AES-128-GCM 和 AES-128-CCM
#define MBEDTLS_CIPHER_AES_128_GCM
#define MBEDTLS_CIPHER_AES_128_CCM

// 关闭调试和自测
// #define MBEDTLS_DEBUG_C
// #define MBEDTLS_SELF_TEST

// 关闭文件系统
// #define MBEDTLS_FS_IO

// 关闭不必要的椭圆曲线，只保留 secp256r1
#define MBEDTLS_ECP_DP_SECP256R1_ENABLED
// #define MBEDTLS_ECP_DP_SECP384R1_ENABLED
// #define MBEDTLS_ECP_DP_SECP521R1_ENABLED

4.2 内存池配置：告别动态内存的噩梦

嵌入式系统里，动态内存分配（malloc/free）是万恶之源。碎片化、不可预测的延迟、内存泄漏，你想想看，一个 TLS 握手过程中突然 malloc 失败，连接直接断掉，这谁能忍？

mbedTLS 提供了内存池机制，让你可以预分配一块静态内存，所有内部的内存分配都在这个池子里完成。我个人强烈建议你在所有 RTOS 或裸机项目中使用这个方案。

配置内存池需要实现几个回调函数：

  • mbedtls_platform_set_calloc_free()：替换默认的 malloc/free。
  • 或者更底层地，实现 MBEDTLS_PLATFORM_STD_CALLOC 和 MBEDTLS_PLATFORM_STD_FREE 宏。

下面是一个典型的内存池实现示例：

#include <stdlib.h>
#include <string.h>

// 预分配一个 16KB 的内存池
#define MEMPOOL_SIZE  (16 * 1024)
static unsigned char mempool[MEMPOOL_SIZE];
static size_t mempool_offset = 0;

// 自定义 calloc
static void *my_calloc(size_t nmemb, size_t size) {
    size_t total = nmemb * size;
    if (mempool_offset + total > MEMPOOL_SIZE) {
        return NULL; // 内存不足
    }
    void *ptr = &mempool[mempool_offset];
    mempool_offset += total;
    memset(ptr, 0, total);
    return ptr;
}

// 自定义 free（这里简单实现，实际项目可能需要更复杂的回收机制）
static void my_free(void *ptr) {
    // 在简单场景下，可以不做回收，或者实现一个简单的 slab 分配器
    (void)ptr;
}

// 初始化时替换
void tls_memory_init(void) {
    mbedtls_platform_set_calloc_free(my_calloc, my_free);
}

注意： 上面的 my_free 实现非常简陋，只适用于连接数固定、内存使用模式可预测的场景。如果你的设备需要频繁创建和销毁 TLS 连接，我建议你实现一个更完善的内存回收机制，比如基于空闲链表的内存池。

内存池的大小怎么定？我一般这样估算：

场景 建议内存池大小 说明
仅 TLS 客户端，单连接 8KB - 16KB 包含握手缓冲区和会话状态
TLS 客户端 + 服务器 32KB - 64KB 服务器需要维护多个会话
使用 PSK 预共享密钥 4KB - 8KB 不需要证书处理，省很多
使用证书 + ECDHE 16KB - 32KB 证书解析和椭圆曲线运算开销大

4.3 随机数生成器：安全性的基石

TLS 的安全性，很大程度上依赖于随机数的质量。如果随机数生成器（RNG）是伪劣的，那你的 TLS 连接就是纸糊的。我见过有人直接用 rand() 来生成随机数，结果每次握手生成的随机数都一样，这跟没加密有什么区别？

mbedTLS 需要一个硬件熵源来提供真正的随机数。你需要实现 mbedtls_hardware_poll() 这个函数。

常见的硬件熵源包括：

  • MCU 内置的 RNG 外设：比如 STM32 的 RNG 模块，NXP 的 RNGA。
  • ADC 噪声：读取悬空 ADC 引脚的噪声值。
  • 传感器噪声：比如温度传感器的低几位抖动。

下面是一个基于 STM32 RNG 外设的实现：

#include "stm32f4xx_hal.h"

extern RNG_HandleTypeDef hrng;

int mbedtls_hardware_poll(void *data, unsigned char *output, size_t len, size_t *olen) {
    (void)data;
    uint32_t random_word;
    size_t i;

    for (i = 0; i < len; i += sizeof(uint32_t)) {
        if (HAL_RNG_GenerateRandomNumber(&hrng, &random_word) != HAL_OK) {
            return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
        }
        // 拷贝到输出缓冲区
        size_t copy_len = (len - i) > sizeof(uint32_t) ? sizeof(uint32_t) : (len - i);
        memcpy(output + i, &random_word, copy_len);
    }

    *olen = len;
    return 0;
}

避坑指南： 我曾经在一个项目里，MCU 的硬件 RNG 在低温环境下初始化失败。后来我加了一个后备方案：如果硬件 RNG 初始化失败，就使用芯片内部唯一 ID 加上系统滴答定时器的低几位来生成一个种子，虽然安全性降低，但至少设备不会死机。

4.4 硬件加速接口：让 TLS 跑得更快

纯软件实现的加密算法在 MCU 上跑起来很慢。一个 ECDHE 握手，如果全靠 CPU 算，可能要好几秒。用户等不了，设备也费电。

现在很多 MCU 都内置了硬件加密引擎，比如 AES 加速器、哈希加速器、甚至椭圆曲线加速器。mbedTLS 允许你通过 ALT 接口（Alternate Implementation）来替换掉软件实现。

你需要关注以下几个关键加速点：

算法 mbedTLS 模块 硬件加速接口
AES-CBC/GCM MBEDTLS_AES_ALT mbedtls_aes_xxx() 系列函数
SHA-256 MBEDTLS_SHA256_ALT mbedtls_sha256_xxx() 系列函数
ECDSA/ECDHE MBEDTLS_ECP_ALT mbedtls_ecp_xxx() 系列函数
RSA MBEDTLS_RSA_ALT mbedtls_rsa_xxx() 系列函数

启用硬件加速的步骤很简单：

  1. 在 mbedtls_config.h 中定义对应的 _ALT 宏。
  2. 实现对应的硬件加速函数。
  3. 将实现文件加入编译。

举个例子，启用 AES 硬件加速：

// 在 mbedtls_config.h 中
#define MBEDTLS_AES_ALT

// 然后你需要实现 mbedtls_aes_init, mbedtls_aes_setkey_enc, mbedtls_aes_crypt_ecb 等函数
// 这些函数内部调用 MCU 的硬件 AES 外设

性能对比（基于 Cortex-M4 @ 168MHz）：

  • 软件 AES-128-GCM：约 15 MB/s
  • 硬件 AES-128-GCM：约 80 MB/s
  • 软件 ECDHE (secp256r1)：约 800 ms
  • 硬件 ECDHE (secp256r1)：约 50 ms

硬件加速带来的性能提升是数量级的，尤其是在握手阶段。

下面这张图展示了 mbedTLS 移植的核心模块关系：

mbedTLS 移植核心模块关系图 mbedTLS 移植核心模块 应用层 (TLS 客户端/服务器) mbedTLS 核心 (SSL/TLS 协议栈) 密码学算法 AES / SHA / ECC / RSA 随机数 & 熵源 硬件 RNG / 熵池 内存管理 内存池 / 静态分配 硬件抽象层 (HAL / 驱动) 裁剪编译决定哪些模块被编译，内存池和 RNG 是运行时基础，硬件加速提升性能

最后，我想强调一点：移植不是一次性的工作。你在项目初期可能只需要一个最小功能集，但随着产品迭代，可能会增加新的密码套件或功能。所以，保持 mbedtls_config.h 的版本管理很重要，我习惯把每个版本的配置都提交到 Git 里，并写上注释说明为什么开启或关闭某个宏。这样，半年后回头看，你还能想起来当初为什么这么干。

← 上一章 📖 返回目录 下一章 →