传输层安全性和安全元素的工作原理

传输层安全性的目的

TLS 的目的是为嵌入式安全支柱做出贡献：

机密性（加密数据）

完整性（保护数据不被篡改/损坏）

身份验证（在客户端和主机之间建立信任）

TLS 和身份验证齐头并进。TLS 将启动并执行加密操作，以建立经过身份验证和加密的通信隧道。安全元素将存储和保护TLS协议请求的相关加密密钥，私钥是迄今为止最关键的密钥。继续阅读以了解为什么如果没有强大的安全密钥存储来保护至少私钥，加密会很弱。

TLS 用于保护网站到网站的通信，也用于保护基于互联网协议 （IP） 的物联网 （IoT） 连接设备。开放系统互连 （OSI） 模型是概念性的，大多数技术并不完全属于这些层。下面显示了 TLS 在会话层和表示层之间的位置。

TLS 和身份验证

TLS 的一个重要部分是身份验证阶段。对于物联网市场，通常的做法是云平台和物联网设备相互进行身份验证，这称为相互身份验证。最常用的技术利用 X509 证书和公钥基础设施，因为它只是在嵌入式 deice 上尽可能优化运行计算饥渴的加密算法所需的处理能力，并保持它们相对实惠。有几个标准，如物联网消费者EN303645，物联网工业IEC / ISA62443，电动汽车充电ISO15118和开放充电点协议（OCPP），都建议使用TLS的安全密钥存储。ISO15118甚至会告诉我们，如果私钥由攻击者控制，并且与支付要交付给车辆的费用相关的金融交易是否可以被冒充并因此被盗。此外，如果您的私钥被盗，攻击可能会渗透到整个网络。

让我们深入了解身份验证原则：

数字签名算法 （DSA）

证书签名

证书验证

证书身份验证

数字签名算法 （DSA）

在这里，我们解释了数字签名算法如何工作的基础知识：

DSA使用宿主和主体的概念。

主持人向主题发送消息。它们中的每一个都有各自的公钥/私钥对，其中公钥是从私钥中计算出来的

主题公钥分发到主机

受试者将提供一个称为签名的答案

签名是使用主题私钥的消息的加密“签名”操作的输出。

然后，主机将使用使用者公钥验证签名。

现在，我们有一个由私钥签名的质询（消息），并获得了由主机公钥验证的签名。请记住：私钥签名，公钥验证。

证书签名

让我们扩大范围并将 DSA 概念扩展到 TLS 中使用的 X509 证书以及对证书的哪一部分进行签名。我们来介绍一下权威和主体关系的概念。两者都有其公钥/私钥对。我们开始使用公钥基础结构 （PKI） 关联到证书链。PKI可以建立在证书链上，证书颁发机构位于链的顶部：颁发机构。

使用者向颁发机构发送证书签名请求 （CSR）

机构将使用其公钥对其进行验证

验证 CSR 后，证书的“待签名”（TBS） 部分将通过前面讨论的 DSA。在此图中，我们将特别提及椭圆曲线数字签名协议（著名的 ECDSA）。

要签名的证书部分包含：

权威信息

证书信息

主题信息

主题公钥

然后我们需要在这组数据的末尾附加签名以转到下一个概念。

证书验证

在上一步中，证书使用颁发机构私钥签名，在使用者和颁发机构之间创建绑定，但绑定尚未完成。主机需要验证使用者证书的签名 TBS 部分是否可信：

主体向主持人（不同于权威机构）提供他的 TBS 和签名。

主机使用先前分发给它的颁发机构公钥，并使用它来验证使用者的签名并收集使用者的 TBS。

在我们的案例中，验证是使用 ECDSA 验证完成的。

现在证书已验证，让我们讨论实际的证书身份验证。

证书身份验证

使用者会将其证书发送到具有权限公钥的主机

使用者证书包含使用者公钥

主机将向主体发送随机质询（也称为随机数），主体将使用 ECDSA 签名操作并使用主体私钥对其进行签名。

签名被发送回主机，主机将使用先前分发的主题公钥对其进行验证。

这是对证书的不同看法。我们可以了解签名的内容，证书的静态部分是什么，证书的动态部分是什么。CryptoAuthLib 是与我们的安全元素一起使用的库，用于处理证书静态和动态部分的解析。公钥、签名和私钥将由安全元素安全边界内的必要加密操作处理。

图 2：完整的 X509 证书

加密和完整性

现在，已经涵盖了身份验证的基本概念，我们可以回顾一下加密和完整性概念以及TLS如何处理它们。

这里的想法是，客户端和物联网世界中的服务器创建了前向保密的概念。为此，我们需要即时生成临时对称密钥，也称为临时密钥。通常，非对称操作很慢，因此对称密钥用于加密和完整性。我们需要从密钥交换（也称为密钥协议）开始。服务器和客户端计算出两端相同的预主密钥。

在加密术语中，我们将使用椭圆曲线Diffie Hellman Ephemeral （ECDHE）操作，如下所示。

每个客户端和服务器发出一个随机数，代表他们自己唯一的私钥

一方面，私钥通过 ECDH 运行，但使用另一端公钥来计算预主密钥。

另一方将执行相同的操作

现在，每一方都有一个相同的预主密钥。接下来，我们需要一个伪随机函数（PRF）来生成额外的密钥材料：

客户端和服务器加密密钥

客户端和服务器初始化向量 （IV）

客户端和服务器消息身份验证代码 （MAC） 密钥

如果我们参考 ATECC608 或 TA100，它们都具有 PRF 模式下的密钥派生函数 （KDF），这是使用 HMAC/SHA1 实现 TLS2.256 PRF 所必需的。让我们看看PRF在TLS中做了什么。

从预主密钥中，PRF 生成更多密钥！从预主密钥中，我们将通过另一个 PRF 运行预主密钥和种子，以计算通常长为 48 字节的主密钥。

“种子”本身由客户端随机数、服务器随机数和主密钥组成。

最后，我们进入密钥扩展阶段，该阶段从前一阶段获取主密钥，包含客户端随机数、服务器随机数和“密钥扩展”的种子。种子和主密钥都通过 PRF 运行以输出密钥材料。

请注意，有单独的加密和完整性检查：

AES128 CBC 用于加密

HMAC-SHA256 用于 MAC

但也有组合的加密和完整性检查：

经过身份验证的关联数据加密 （AEAD）

GCM - 伽罗瓦计数器模式

CCM - 带 CBC-MAC 的计数器

下面我们将说明 ATECC608 或 TA100 将实现的对称加密流。它说明了如何使用所讨论的步骤建立前向保密。

TLS 握手和密码套件

TLS构建得非常灵活，并提供不同的密码套件。每个密码套件都由多个加密参数组成，我们刚刚在这篇博文中回顾了这些参数。

密钥交换算法

身份验证算法

密码

算法、密钥强度、模式

MAC 或 PRF

您可以在以下链接中参考密码套件的广泛列表。如果您考虑所有现有的密码套件，则必须考虑嵌入式系统的限制。嵌入式物联网设备（如烟雾探测器或监控摄像头）没有数据中心的马力 - 您会认为这是显而易见的，对吧？三思而后行。通常，嵌入式系统的计算能力最小，内存有限，功耗有限，安全性会打击所有三个系统，因为加密可能会耗费计算，从而影响功耗。就此而言，我们将把示例重点放在以下密码套件 ATECC608 excel 上，因为它提供了非常成本优化的体系结构和高级别的密钥保护（通用标准联合解释库 （JIL） 高）： TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256，让我们分解它：

ECDHE 密钥交换/协议算法

ECDSA 服务器身份验证算法

AES 密码算法

128 密码强度

GCM 密码模式

SHA256 PRF（伪随机函数）

密码模式为 AEAD（结合加密和完整性检查）

最后一部分指定 PRF 算法。

您需要 RSA 吗？请考虑 TA100 和以下密码套件：TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256。 我们已经看到它用于汽车应用，但也用于基于Linux®的应用，如网关，需要网络密码改造，因为旧的连接设备仍然对基础设施至关重要，在带有RSA的网络上运行。同样，我们有以下密码学：

ECDHE 密钥交换/协议算法

RSA 服务器身份验证算法

AES 密码算法

128 密码强度

CBC 密码模式

SHA256 MAC（消息身份验证代码）

它将加密和完整性检查算法分开。最后一部分指定 MAC 算法。

如您所见，ECC 私钥或 RSA 私钥是安全建立 TLS 会话的最重要基础的机密。如果该密钥是公开的或可访问的，则依赖于它的任何加密都与公开的密钥一样弱。因此，必须通过在 TA608 安全元件的 ATECC100 中隔离私有设备来保护私有设备。这样，私钥就与代码、用户、开发人员和制造商“隔绝”。在使用 Microchip 安全配置服务时，这种隔离性会更加增强。以下是 TA100 将支持的一组密码套件作为示例：

TLS1.2 ： TLS_ECDHE_WITH_AES_128+CBC+SHA256 RSA AES_123 CBC SHA256

TLS1.3 ： TLS_AES_128_GCM_SHA256

TLS1.3 ： TLS_AES_128_CCM_SHA256

TLS1.3 ： TLS_AES_128_CCM_8_SHA256

如何使用 ATECC608 或 TA100 实现 TLS：信任平台设计套件

让我们动手操作代码和硬件，并查看实现细节。首先，下载信任平台设计套件。这里有几个TLS用例，包括简化的交易图和交钥匙C代码项目，以帮助您开始使用我们的安全元件，微控制器和WiFi模块：

Trust&GO ATECC608 for AWS IoT

Trust&GO ATECC608 for Microsoft Azure

适用于 AWS IoT 的 TrustFLEX ATECC608

TrustFLEX ATECC608 for Microsoft Azure

在TPDS之外，你可以找到来自WolfSSL和mbedTLS的代码示例，利用PKCS#11 for Linux®平台。

现在我们将详细介绍涉及 ATECC608 的 TLS 的实际事务图。TA100在概念上是相似的（使用talib而不是atcab进行API调用）。下图主要关注微控制器单元 （MCU） 和 ATECC608 之间的 CryptoAuthLib 回调。您可以通过搜索“atcab”API 调用轻松识别它们。

 

 

这就是实现带有安全元素的TLS的方式。请记住下载信任平台设计套件并测试 C 代码项目。请记住，此安装意味着您选择的TLS堆栈需要具有对CryptoAuthlib的回调，例如mBedTLS或WolfSSL。请注意，我们的WFI32 WiFi MCU模块将WiFi堆栈与TLS和微控制器集成在一个模块或芯片架构中。 如果您的系统具有某种类型的操作系统或RTOS，那么您可以使用PKCS#11访问CrytpoAuthLib API并向安全元素发送命令。PKCS#11 将删除与 TLS 堆栈提供程序的任何依赖项，但需要一个能够通过 PKCS#11 进行通信的嵌入式系统。如果您有裸机实施，那么我们提供的说明将满足您的系统要求。

审核编辑：郭婷