第 1 章：Azure RTOS NetX Secure 简介
Azure RTOS NetX Secure 是加密网络安全标准的高性能实时实现，包括专为基于嵌入式 ThreadX 的应用程序设计的 TLS/SSL。 本章介绍了 NetX Secure，并说明了其应用范围和权益。
NetX Secure 的独特功能
与大多数其他 TLS 实现不同，NetX Secure 是从头开始设计的，可支持各种嵌入式硬件平台，并可轻松地从小型微控制器应用程序缩放到可用的最强劲嵌入式处理器。 编写代码时，需要考虑有限的嵌入系统资源，该代码还提供了许多配置选项来降低通过 TLS 提供安全网络通信所需的内存占用量。
NetX Secure 支持的 RFC
NetX Secure 支持以下与 TLS 相关的协议。 此列表并不一定全面，因为有许多 RFC 与 TLS 和加密有关。 NetX Secure 遵循的是所有常规建议和基本要求，并且受在具有小型内存占用量和高效执行的实时操作系统的约束。
| RFC | 说明 | 页 |
|---|---|---|
| RFC 2104 | HMAC：用于消息身份验证的基于哈希的消息验证码 | 33 |
| RFC 2246 | TLS 协议版本 1.0 | 19 |
| RFC 3268 | 用于传输层安全 (TLS) 的高级加密标准 (AES) 密码套件 | 31 |
| RFC 3447 | 公钥加密标准 (PKCS) #1：RSA 加密规范版本 2.1 | 32 |
| RFC 4279 | 用于 TLS 的预共享密钥密码套件 | 39 |
| RFC 4346 | 传输层安全性 (TLS) 协议版本 1.1 | 19 |
| RFC 5246 | 传输层安全性 (TLS) 协议版本 1.2 | 19 |
| RFC 5280 | X.509 PKI 证书 (v3) | 41 |
| RFC 5746 | 传输层安全性 (TLS) 重新协商指示扩展 | |
| RFC 5869 | 基于 HMAC 的提取和扩展密钥派生功能 (HKDF) | 19 |
| RFC 60661 | 传输层安全性 (TLS) 扩展：扩展定义 | 19 |
| RFC 6234 | 美国安全哈希算法（SHA 和基于 SHA 的 HMAC 和 HKDF） | 33 |
| RFC 8443 | 用于传输层安全 (TLS) 版本 1.2 及更低版本的椭圆曲线密码学 (ECC) 密码套件 | |
| RFC 8446 | 传输层安全性 (TLS) 协议版本 1.3 | 19 |
- 从版本 6.0 开始，仅完全支持 RFC 6066 中的服务器名称指示 (SNI) 扩展。
NetX Secure 要求
为了正常运行，NetX Secure 运行时库需要已创建 NetX IP 实例。 此外，根据不同的应用程序，还需要一个或多个采用 DER 编码的 X.509 数字证书，用于标识 TLS 实例或验证来自远程主机的证书。 NetX Secure 包没有进一步的要求。
NetX Secure 约束条件
NetX Secure 协议实现了适用于 TLS 1.2 的 RFC 5246 标准 和适用于 TLS 1.3 的 RFC 8446 要求，并为 RFC 4346 (TLS 1.1) 和 2246 (TLS 1.0) 提供可选的（默认禁用）向后兼容性。 但，这具有以下限制：
- TLS 1.2 和 TLS 1.3 仅支持使用 SHA-256 的密码套件。 在 TLS 1.2 之前的版本中，TLS 握手使用固定的哈希例程来验证 TLS 握手消息是否未遭篡改。 从版本 1.2 开始，握手使用随密码套件提供的哈希例程。 TLS 不会提前得知要使用的哈希例程，并且必须缓存握手消息。 通过修复 SHA-256 的哈希，NetX Secure TLS 可以在 RAM 占用空间比其他 TLS 实现更小的情况下运行。 一旦可以正确地处理内存使用情况，此限制会在将来的版本中删除。 \* 重要提示：此限制仅适用于密码套件选择。 X.509 证书签名不受相同的限制约束，可使用任何受支持的哈希例程。
- 由于嵌入式设备的性质，某些应用程序可能没有相关资源来支持最大 TLS 记录大小：16KB。 NetX Secure 可以在具有足够资源的设备上处理 16KB 记录。 TLS 重新组合缓冲区（参阅关于 nx_secure_tls_session_packet_buffer_set 的 API 参考）可能会设置为小于 16KB 的大小，同时降低互操作性问题的风险。 如果收到的有效 TLS 记录大于重新组合缓冲区，NetX Secure TLS 将中止 TLS 会话，并显示错误。 通常情况下，缓冲区应始终设置为至少 18KB（16KB TLS 记录大小 + 2KB，以便进行加密填充），并且仅在受控设置中可以设置更小值，例如，远程主机保证最大的 TLS 记录大小。
注意
通常，数据包重组缓冲区绝不应小于 TLS 最大记录大小。 但是，如果远程主机的特征是众所周知的（例如，在完全关闭的系统中），你可降低大小以重新获取一些 RAM 空间。
- 证书验证最低要求。 NetX Secure 会对证书执行基本的 X.509 链验证，以确保证书有效并由受信任的证书颁发机构签名，并可以为应用程序提供证书公用名，以与远程主机的顶层域名进行比较。 如果实时时钟可用，可以使用它来验证证书的到期日期（参阅 API nx_secure_tls_session_time_function_set）。 不过，验证证书扩展和其他数据是应用程序实施者的责任。
- 基于软件的加密需要大量处理器。 基于 NetX Secure 软件的加密例程已优化性能，但根据目标处理器的强大功能，该性能可能导致操作时间变长。 当使用基于硬件的加密时，它应该用于 NetX Secure TLS 的最佳性能。
- TLS 握手记录碎片不受支持。 如果某些 TLS 握手记录消息太大，则系统可能会将这些记录拆分到多个 TLS 记录中 — NetX Secure TLS 当前将此消息视为错误。 根据嵌入系统的内存要求，系统可能仍无法处理较大的握手记录消息，但当与使用过大型证书链的某些 TLS 主机进行通信时，此限制可能导致错误。
- 当本地存储中有多个证书时，TLS 服务器不支持动态证书选择。
- 未观察到 X509 证书密钥使用情况。
- 不支持基于 ECDH 的密码套件。 改用 ECDHE。