使用安全配套IC保护TLS实现

保护在我们众多智能互联设备和云之间收集和共享的敏感数据比以往任何时候都更加重要。工业传感器、家用电器、可穿戴医疗设备等都利用数据，如果落入坏人之手，可能会导致严重后果。

传输层安全性 （TLS） 协议（以前称为安全套接字层 （SSL））是用于保护传输中的数据的最常用协议。虽然它最初是为通过互联网、计算机和网站之间的双向安全通信而创建的，但现在 TLS 协议对于保护物联网设备在互联网上的通信、防止窃听或篡改传输中的数据至关重要。该协议被认为是健壮的，因为它已被大量研究、攻击和修复并被广泛采用。为了确保TLS协议在设备端可以信任，必须将永远不得泄露或修改的密钥，私钥和证书存储在设备中，并在协议执行过程中使用。但是，由于物联网设备部署在野外，这些安全资产可能会暴露给可能尝试侵入性和非侵入性攻击的攻击者。在侵入性攻击中，网络犯罪分子打开设备的外壳以操纵其内存内容、更换固件或探测 PCB 走线。非侵入性类型通常通过通信端口执行，针对设备固件中的逻辑错误。如果没有安全的IC伴侣，保护TLS实现就变得不可能。

本应用笔记讨论了一种低成本、低复杂度的解决方案，用于保护互联嵌入式系统中的TLS实现，同时减轻器件应用处理器的负担。

概述：TLS 协议

TLS 发生在客户端和服务器之间。在本应用笔记中，“客户端”是嵌入式系统（例如物联网设备），“服务器”是云中的远程机器，可通过互联网访问。我

因此，让我们想象一个带有传感器和执行器的“客户端”设备，它连接到“服务器”提供的 Web 服务。基于此方案，用户可以使用智能手机查看传感器数据，并通过服务器向设备发送命令。客户端设备使用 TLS 向服务器报告数据或从服务器获取命令。

TLS 协议有两个主要阶段：

建立（握手）

安全通信（通过身份验证和加密安全传输应用程序数据）

建立（握手）阶段

握手阶段是安全通信配置的协商。该阶段包括服务器和客户端身份验证，以及共享密钥的计算。此阶段的四个步骤如下：

关于密码套件的协议，该套件是将在以下后续阶段中使用的加密算法的集合。服务器和客户端决定使用哪组加密协议来协商共享密钥和应用程序通信的安全性。

客户端对服务器的身份验证。在此阶段，客户端向服务器发送由随机字节序列组成的消息。作为交换，服务器将自己的证书以及使用此随机消息的数字签名（使用服务器的私钥计算）发送回客户端。然后，客户端使用服务器的证书验证邮件的签名（在验证此证书之后）。

（可选）服务器对客户端进行身份验证。此步骤在嵌入式系统中很有用，其过程与步骤 2 相同。独立客户端设备不能“输入其密码”来向服务器进行身份验证，这是网站上的常见做法。TLS 握手使用一个选项来解决此问题，该选项要求客户端使用其客户端私钥提供数字签名来证明其身份（遵循与步骤 2 中的服务器身份验证完全相同的方案）。

安全通信阶段的共享通信密钥（例如，AES密钥）的协商。在此步骤中，可以使用复杂的基于公钥的密钥交换协议（如 ECDHE）交换密钥。这些协议允许在客户端和服务器端计算相同的密钥或对称密钥，而无需实际传输它。然后，在下一阶段使用密钥交换中的密钥对服务器和客户端之间交换的消息进行加密和签名。这些密钥用于所谓的对称加密（相同的密钥用于加密和解密，或两端的签名和验证，如基于 AES 的算法）。低内存使用率和高性能要求推动了使用对称加密的需求。与AES相比，基于RSA或EC公钥的算法将非常慢和/或缺乏资源。但是，分发用于安全通信的密钥需要使用基于 RSA 或 EC 的算法进行密钥协商阶段的复杂性。

预共享（秘密）密钥交换算法提供了基于公钥的密钥交换算法的替代方法。在此方案中，在现场释放设备之前，在服务器和设备中加载相同的密钥。虽然此选项消除了实施 RSA 或 EC 加密的负担，但它需要在设备和服务器上长期存储相同的密钥。然而，这种方法是有风险的，因为如果所有连接的对象共享相同的密钥，则泄露单个密钥会危及整个网络。

安全通信阶段

使用上述过程交换共享通信密钥后，将建立安全的通信通道;两个通信方可以开始交换应用程序级数据（例如，HTTP请求/响应）。TLS 协议层自动加密和签名发送的数据包，并在接收端解密和验证收到的数据包。该层使用基于密钥的算法（例如用于加密的 AES-CBC、用于签名的 AES-CMAC 或用于同时加密和签名的较新的风格（如 AES-CCM）来实现此目的。如果传入消息已损坏，则 TLS 协议层将返回错误。

通信结束后，共享通信密钥（也称为会话密钥）将被丢弃。

红绿灯的缺点

从软件的角度来看，TLS协议可以使用现成的软件库（如mbedTLS，https://tls.mbed.org）轻松集成到任何应用程序中。这种库的软件集成似乎很容易做到。毕竟，当使用 TCP/IP 协议通过互联网进行通信时，应用程序通常使用 POSIX 套接字 API 的“连接”、“读取”和“写入”功能。要使用 TLS，应用程序只需在使用 mbedTLS 库时将这些调用重定向到例如“mbedtls_ssl_connect”、“mbedtls_ssl_read”和“mbedtls_ssl_write”。应用程序源代码不需要包含实现TLS主要阶段的所有几率：“mbedtls_ssl_connect”自动执行身份验证和密钥协商，“mbedtls_ssl_read”和“mbedtls_ssl_write”自动将TLS保护（加密和签名）添加到传入和传出的应用程序数据传输（例如HTTP请求/响应）。

此图提供了 TLS 实现的粗略图片。

尽管看起来很简单，但将TLS库集成到应用程序及其配置（包括服务器上的配置）中也存在一些缺点。即使使用无错误的TLS堆栈，软件中TLS库的集成和使用也可能有缺陷。

本应用笔记的以下部分将探讨客户端（即嵌入式器件）TLS集成的常见弱点。

跳过的证书验证

应用程序在使用 TLS 库时经常看到的第一个问题与证书验证有关。

应用程序的角色是强制验证服务器证书，因此 TLS 库通常不会自动执行此操作。他们必须明确请求从 TLS 库进行验证。但是，如果没有这个基本的验证步骤，通信可能会受到“中间人”攻击。

图2.中间人攻击。第二

假设网络流量被转移到不是预期服务器的计算机。通过不验证对等证书，客户端与攻击者建立错误可信的 TLS 通道。发生这种情况时，TLS 协议变得毫无用处，更糟糕的是，会给人一种错误的安全印象。

弱密码套件

TLS 故障可能源于服务器的配置。例如，可以将服务器配置为接受弱密码套件。弱密码套件通常使用已弃用或损坏的加密算法（如 RC4），这些算法太弱而无法抵御最先进的攻击。通常，从安全角度来看，TLS 协商阶段会利用客户端和服务器都支持的最强协议配置。但是，如果服务器支持过时的加密算法，则攻击者可以降低服务器和客户端之间交换的安全性，并访问交换的数据。同样，一些算法使用前向保密，这可以保护过去的会话免受将来密钥或密码的泄露。使用临时Diffie-Hellman（DHE）或椭圆曲线变体（ECDHE）的密码套件具有完美的前向保密性 - 这些是服务器应该实现的密码套件。有些选项没有完全的前向保密。

易受攻击的证书颁发机构证书

有效验证服务器证书是抵御中间人攻击不可或缺的一部分。存储在嵌入式系统中的根证书验证服务器的证书。根证书通常在嵌入式设备制造过程中加载，属于证书颁发机构，该证书颁发机构颁发设备和服务器证书，可以保证其完整性。如果此根证书被设备长期内存中的流氓证书替换，则该证书可能会成为安全漏洞的受害者。发生这种情况时，攻击者的服务器可以成功验证为有效服务器，因为恶意服务器的证书将由恶意加载到客户端设备的恶意根证书正确验证。此方案还需要某种形式的中间人攻击;但是，这并不难做到。

公开的会话密钥

会话密钥是安全武器库中的短期秘密武器：只要TLS安全通信通道，它们的有效性就会持续。一组会话密钥不能用于猜测另一组会话密钥。但是，如果这些密钥泄露，这仍然会危及整个 TLS 会话，无论是记录的过去会话还是当前正在运行的会话。

客户端身份验证密钥泄露

TLS 协商阶段可以包括客户端向服务器进行身份验证的步骤。如果客户端公开其私钥以向服务器进行身份验证，则客户端可由重复使用该密钥的攻击者模拟。

糟糕的加密实现和低质量的随机数

如果设备的长期记忆被转储，则此密钥的暴露可能是“立即”的。这种暴露也可能是间接的，因为所使用的加密算法虽然功能正确，但不能抵抗侧信道攻击。在侧信道攻击中，攻击者可以通过测量设备的时序和/或功耗和/或电磁辐射来猜测私钥或密钥，当它运行涉及此类密钥的加密算法时。

启用更安全的客户端 TLS 实现

有一组最低规则需要遵循，以维护真正安全的TLS方案，并减轻本应用笔记中讨论的陷阱：

CA 证书必须是真正不可变的。只有设备制造商或运营商才能替换根证书。然后，挑战在于保护对存储证书的内存的访问，因为注入嵌入式系统应用处理器中的任何软件都可以修改内存。

客户端必须始终检查服务器证书以避免 MITM 攻击。

必须安全存储客户端的私有身份验证密钥

必须使用安全的加密算法实现（并且能够抵抗侧信道分析）

TLS库必须由应用程序正确集成和配置，才能安全运行

配套安全 IC 如何保护 TLS 实施

客户端的 TLS 握手阶段涉及以下长期资产：

服务器证书

证书颁发机构证书（根之一）

客户端私钥（如果使用）

预共享密钥（如果使用）

使用安全IC，如MAXQ1061，通过设计防止上述漏洞，保护TLS实现，而不会给应用处理器带来任何额外的负担。

MAXQ1061将CA根证书存储在内部非易失性存储器中。这些证书只能替换为正确的基于公钥的强身份验证。通常，远程管理员执行这种强认证，并且是唯一拥有私钥以激活对MAXQ1061的访问的实体。

MAXQ1061管理TLS握手阶段，始终保证：

防止 MITM 攻击。在使用之前，始终会验证服务器证书。MAXQ1061拒绝使用任意公钥或证书进行进一步的签名验证。在使用前，必须使用MAXQ1061中已有的有效证书对该公钥进行签名。

由于它们是使用最先进的加密技术（高质量的随机数，无侧信道泄漏）计算的，因此会话密钥不会泄漏

由于客户端认证是使用存储在MAXQ1061长期存储器中的私钥执行的，因此不能模拟客户端。这些密钥始终使用高质量的随机数生成器在内部生成。根据设计，它们不能从IC中提取。

无法使用弱密码套件。只有具有 AES-CCM 或 AES-GCM 和 SHA-256 或更多密码套件的 ECDHE-ECDSA 可用。

MAXQ1061仅在安全启动成功时允许客户端认证。只要应用处理器的固件和配置尚未成功验证，此安全IC就可能使身份验证私钥无法使用。使用此方法，客户端设备只有在未被篡改的情况下才能作为正版设备进行身份验证。此外，具有MAXQ1061的器件无法克隆：由于该安全IC包含唯一的私钥，因此不可能伪造该安全IC。

Maxim提供的基于mbedTLS的略微修改的TLS堆栈允许应用处理器利用MAXQ1061的上述特性，无需进行重大的重新设计即可提供更高的安全级别。修改后的mbedTLS堆栈利用MAXQ1061进行会话密钥交换、服务器证书验证和客户端认证。安全通信本身可以由MAXQ1061本身或主应用处理器进行。

上述讨论并不排除服务器端的任何弱点。不用说，必须遵循安全措施来保护服务器私钥和证书链。

结论

保护嵌入式系统需要强大的软件编码和锁定的系统门（物理和逻辑）。不要低估攻击者也是值得的。

在安全的 IC 中存储长期机密（如用于身份验证的私钥）或证书等重要数据更安全、更容易。另一种方法是将这些资产存储在通用应用处理器中，但这些处理器通常通过设计提供许多调试功能，这些功能可以访问其整个内存内容。将安全IC与应用处理器一起使用的另一个好处是，两个IC之间的物理隔离保证了应用处理器中的软件漏洞不会危及存储在安全IC中的资产。

审核编辑：郭婷