mbedtsl与openssl的区别，物联网嵌入式一般用哪个？

Posted 2023-03-18

mbedtsl与openssl的区别，物联网嵌入式一般用哪个？
如果有用mbedtls-https访问阿里云物联网的列子，最好啦！

物联网用mbed
什么是 SSL, 什么是 TLS 呢？

官话说 SSL 是安全套接层 (secure sockets layer)，TLS 是 SSL 的继任者，叫传输层安全 (transport layer security)。

说白点，就是在明文的上层和 TCP 层之间加上一层加密，这样就保证上层信息传输的安全。如 HTTP 协议是明文传输，加上 SSL 层之后，就有了雅称 HTTPS。它存在的唯一目的就是保证上层通讯安全的一套机制。

它的发展依次经历了下面几个时期，像手机软件升级一样，每次更新都添加或去除功能，比如引进新的加密算法，修改握手方式等。
SSL1.0: 已废除 SSL2.0: RFC6176, 已废除
SSL3.0: RFC6101, 基本废除
TLS1.0: RFC2246, 目前大都采用此种方式
TLS1.1: RFC4346 TLS1.2: RFC5246, 没有广泛使用
TLS1.3:IETF 正在酝酿中

下面我们将介绍 TLS1.x 如何保证通讯安全。
二: CA & SSL Server & SSL Client 介绍
如何保证安全呢？你说安全就安全吗，究竟是怎么实现的呢？绝对安全吗？ 哈，有人的地方就有江湖，有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。下面根据图一 SSL/TLS 工作流来一览实现过程。
2.1 SSL/TLS 工作流
image
图一 SSL/TLS 工作流
CA: 证书授权中心 (certificate authority)。 它呢，类似于国家出入境管理处一样，给别人颁发护照；也类似于国家工商管理局一样，给公司企业颁发营业执照。

它有两大主要性质：
CA 本身是受信任的 // 国际认可的
给他受信任的申请对象颁发证书 // 和办理护照一样，要确定你的合法身份，你不能是犯罪分子或造反派。
当然，你需要被收保护费，同时，CA 可以随时吊销你的证书。 证书长啥样？其实你的电脑中有一堆 CA 证书。你可以看一看嘛：
360 浏览器: 选项 / 设置 -> 高级设置 -> 隐私于安全 -> 管理 HTTPS/SSL * 证书 -> 证书颁发机构
火狐浏览器: 首选项 -> 高级 -> 证书 -> 查看证书 -> 证书机构
chrome 浏览器: 设置 -> 高级 -> 管理证书 -> 授权中心
ubuntu: /etc/ssl/certs

这些都是 CA 的证书！
CA 的证书 ca.crt 和 SSL Server 的证书 server.crt 是什么关系呢？
SSL Server 自己生成一个 私钥 / 公钥对。server.key/server.pub //私钥加密，公钥解密！
server.pub 生成一个请求文件 server.req. 请求文件中包含有 server 的一些信息，如域名 / 申请者 / 公钥等。
server 将请求文件 server.req 递交给 CA，CA 验明正身后，将用 ca.key 和请求文件加密生成 server.crt
由于 ca.key 和 ca.crt 是一对, 于是 ca.crt 可以解密 server.crt. 在实际应用中：如果 SSL Client 想要校验 SSL server. 那么 SSL server 必须要将他的证书 server.crt 传给 client. 然后 client 用 ca.crt 去校验 server.crt 的合法性。如果是一个钓鱼网站，那么 CA 是不会给他颁发合法 server.crt 证书的，这样 client 用 ca.crt 去校验，就会失败。

比如浏览器作为一个 client, 你想访问合法的淘宝网站https://www.taobao.com, 结果不慎访问到https://wwww.jiataobao.com , 那么浏览器将会检验到这个假淘宝钓鱼网站的非法性，提醒用户不要继续访问！这样就可以保证了 client 的所有 https 访问都是安全的。
2.2 单向认证双向认证
何为 SSL/TLS 单向认证，双向认证？单向认证指的是只有一个对象校验对端的证书合法性。 通常都是 client 来校验服务器的合法性。那么 client 需要一个 ca.crt, 服务器需要 server.crt,server.key双向认证指的是相互校验，服务器需要校验每个 client,client 也需要校验服务器。 server 需要 server.key 、server.crt 、ca.crt client 需要 client.key 、client.crt 、ca.crt
2.3 证书详细工作流
image
图二 证书详细工作流
1）申请认证：服务器需自己生成公钥私钥对 pub_svr & pri_svr，同时根据 pub_svr 生成请求文件 csr, 提交给 CA，csr 中含有公钥、组织信息、个人信息 (域名) 等信息。(图一中 server.req 就是 csr 请求文件)
2）审核信息：CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。
3）签发证书：如信息审核通过，CA 会向申请者签发认证文件 - 证书。 证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。（图一中生成 server.crt）
4）返回证书：client 如果请求验证服务器，服务器需返回证书文件。（图一中 handshake 传回 server.crt）
5）client 验证证书：client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。 客户端会内置信任 CA 的证书信息 (包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。(图一中 check 可选，我们可以选择不验证服务器证书的有效性)
6）秘钥协商：验证通过后，Server 和 Client 将进行秘钥协商。接下来 Server 和 Client 会采用对称秘钥加密。(对称加密时间性能优)（图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程）
7）数据传输：Server 和 Client 采用对称秘钥加密解密数据。
2.4 SSL/TLS 单向认证流程
image
(1)client_hello
客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
支持的最高 TSL 协议版本 version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;
客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密) 和信息摘要 Mac(完整性校验);
支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;
随机数 random_C，用于后续的密钥的生成;
扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
(2).server_hello+server_certificate+sever_hello_done
server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;
server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;
server_hello_done，通知客户端 server_hello 信息发送结束;
(3). 证书校验
[证书链] 的可信性 trusted certificate path，方法如前文所述;
证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
有效期 expiry date，证书是否在有效时间范围;
域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥; enc_key=Fuc(random_C, random_S, Pre-Master)
change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
(5).change_cipher_spec+encrypted_handshake_message
服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥: enc_key=Fuc(random_C, random_S, Pre-Master);
计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
(6). 握手结束
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
(7). 加密通信
开始使用协商密钥与算法进行加密通信。
2.5 实际 wireshark 分析
image我们搭建的 SSL/TLS 服务器是 192.168.111.100,client 是 192.168.111.101. client 需要认证 server 的合法性。 我们只看 TLSv1.1 的数据包：
第一包 (No. 25) Client Hello 包，即 SSL/TLS 单向认证流程的 (1)
第二包 (No. 27) Server Hello 包，包含服务器证书等。即 SSL/TLS 单向认证流程的 (2)
第三包 (No. 28) 服务器证书验证完成，同时发送 client key exchange+change cipher spec + encrypted handshake message. 即 SSL/TLS 单向认证流程的 (4)
第四包 (No. 29) 秘钥协商，change cipher spec + encrypted hanshake message. 即 SSL/TLS 单向认证流程的 (5)
第五包 (No. 30) 握手完成。开始上层数据传输。SSL/TLS 单向认证流程的 (7)
2.6 SSL/TLS 双向认证流程
和单向认证几乎一样，只是在 client 认证完服务器证书后，client 会将自己的证书 client.crt 传给服务器。服务器验证通过后，开始秘钥协商。实际 wireshark 分析：
image
和单向认证一样: 我们搭建的 SSL/TLS 服务器是 192.168.111.100,client 是 192.168.111.101. client 需要认证 server 的合法性，server 也需要认证 client 的合法性！

我们只看 TLSv1.1 的数据包：
第一包 (No. 55) Client Hello 包，即 SSL/TLS 单向认证流程的 (1)
第二包 (No. 57) Server Hello 包，包含服务器证书等。即 SSL/TLS 单向认证流程的 (2)
第三包 (No. 60) 服务器证书验证完成，同时发送客户端的证书 client.crt , 同时包含 client key exchange+change cipher spec + encrypted handshake message. 即 SSL/TLS 单向认证流程的 (4)
第四包 (No. 61)服务器验证客户端证书的合法性。通过后进行秘钥协商，change cipher spec + encrypted hanshake message. 即 SSL/TLS 单向认证流程的

(5)重传包 (No. 62) 由于网络原因，TCP 重传第 No. 60 包。
第五包 (No. 64) 握手完成。开始上层数据传输。SSL/TLS 单向认证流程的 (7)
2.7 证书等格式说明
crt/key/req/csr/pem/der 等拓展名都是什么东东？
带有私钥的证书 PKCS12(P12)

包含了公钥和私钥的二进制格式的证书形式，以 pfx 作为证书文件后缀名。
二进制编码的证书（DER）

　　证书中没有私钥，DER 编码二进制格式的证书文件，以 .cer 作为证书文件后缀名。
Base64 编码的证书（PEM）

　　证书中没有私钥，Base64 编码格式的证书文件，也是以 .cer 作为证书文件后缀名。
.crt 表示证书, .key 表示私钥, .req 表示请求文件,.csr 也表示请求文件, .pem 表示 pem 格式，.der 表示 der 格式。

文件拓展名你可以随便命名。只是为了理解需要而命名不同的拓展名。但文件中的信息是有格式的，和 exe，PE 格式一样, 证书有两种格式。

pem 格式和 der 格式。所有证书，私钥等都可以是 pem, 也可以是 der 格式，取决于应用需要。

pem 和 der 格式可以互转:
openssl x509 -in ca.crt -outform DER -out ca.der //pem -> der
openssl x509 -inform der -in ca.der -out ca.pem // der -> pem

pem格式：经过加密的文本文件，一般有下面几种开头结尾：

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
or:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
or:
----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

der 格式: 经过加密的二进制文件。
证书中含有 申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。如查看百度证书详细信息。
a) 先下载百度证书

火狐浏览器访问https://www.baidu.com/, 点击左上角绿色小锁，点击向右箭头，点击更多信息，点击查看证书，点击详细信息，点击导出。即可导出百度的证书 baiducom.crt
b) 命令查看证书详细信息
openssl x509 -noout -text -in baiducom.crt

image
详细信息中，有一个字段：X509v3 Basic Constraints: CA: FALSE

该字段指出该证书是否是 CA 证书，还是一般性的非 CA 证书。详细描述见RFC5280#section-4.2.1.9，同时 RFC5280 也详细描述证书工作方式等。
私钥加密，公钥解密！
2.8 SSL/TLS 和 Openssl,mbedtls 是什么关系？
SSL/TLS 是一种工作原理，openssl 和 mbedtls 是 SSL/TLS 的具体实现，很类似于 TCP/IP 协议和 socket 之间的关系。
三: 为Tomcat生成和配置HTTPS证书
单向：
-- 为服务器生成证书
keytool -genkey -dname "cn=programmer, ou=JavaSoft, o=Sun, c=US" -keyalg RSA -keysize 1024 -alias tomcat -keypass changeit -keystore server.keystore -storepass changeit -validity 3600
配置Tomcat根目录下的/conf/server.xml

双向：
-- 为服务器生成证书
keytool -genkey -dname "cn=programmer, ou=JavaSoft, o=Sun, c=US" -keyalg RSA -keysize 1024 -alias tomcat -keypass changeit -keystore server.jks -storepass changeit -validity 3600
-- 为客户端生成证书

-- 双击.p12文件，按照提示安装证书，将证书填入到“受信任的根证书颁发机构”
keytool -genkey -v -alias client -keyalg RSA -storetype PKCS12 -keystore client.p12 -dname "cn=programmer, ou=JavaSoft, o=Sun, c=US"
-- 必须把客户端证书添加为服务器的信任认证。由于不能直接将PKCS12格式的证书库导入，必须先把客户端证书导出为一个单独的CER文件
keytool -export -alias client -keystore client.p12 -storetype PKCS12 -storepass changeit -rfc -file client.cer
-- 将该文件导入到服务器的证书库，添加为一个信任证书
keytool -import -v -file client.cer -keystore server.jks
-- 把服务器证书导出为一个单独的CER文件，使用如下命令

-- 双击.cer文件，按照提示安装证书，将证书填入到“受信任的根证书颁发机构”
keytool -keystore server.jks -export -alias tomcat -file server.cer
配置Tomcat根目录下的/conf/server.xml 参考技术A 关于PolarSSL
mbed TLS（以前称为PolarSSL）是TLS和SSL协议的实现，并且需要相应的加密算法和支持代码。这是双重许可与Apache许可证 2.0版（与GPLv2许可也可）。网站上指出，mbed TLS的目标是“易于理解，使用，集成和扩展”
核心SSL 库用C编程语言编写，并实现SSL模块，基本加密功能并提供各种实用功能。与OpenSSL和TLS的其他实现不同，mbed TLS设计为适合小型嵌入式设备。

论物联网与嵌入式异步编程

1. 背景知识

在IT技术高速发展到今天，在为我们的生活带来了翻天覆地的变化的同时。如何更有效的利用计算机资源为我们更好的服务的思考，一直是各大厂商与技术大牛们为之孜孜不倦奋斗的方向。

虽然硬件性能在被不断的提升，然而需求的增长速度还是远远的超过了硬件性能的增长速率，因此人们不断的提出各种编程模型想要以此来用软件的方式来弥补硬件性能上的不足。

尤其是物联网行业，其产品对功耗敏感，对成本也敏感，然而却又要求能够有较高的并发性，同时还要要求能较多的完成规定的任务。因此对编程模型的选择开始变的复杂了起来。时至今日，在IT行业中普遍采用的编程模型有以下这么几种。

2. 现有编程模型

编程模型也就是为了解决某一类的具体问题，然后经过长时间的经验积累总结的适用于解决某种问题的编程套路。现在最常见的有在嵌入式编程中普遍采用的循环加中断的方式，与在实时系统中采用的基于操作系统的多线程编程等。

2.1 循环加中断

循环加中断的编程模型在单片机等嵌入式设备中被普遍采用，其编程模型可以概括为下图形所示的样子。

在这种编程模型中，往往有明确的函数执行入口main，系统在执行完必备的初始化操作后，就将控制权完全的交给main函数，然后其他的一切操作都是从main函数开始。

main函数中会对需要使用到的外设进行必要的初始化等工作，然后系统会进入到一种循环等待的状态，俗称死循环。直到中断到达后会暂停当前的死循环，然后转去执行别的操作，执行完毕后继续退回到死循环中。如果没有中断到来的话，那么就一直执行死循环中的代码。

在本模型中以中断的方式替代了以轮询的方式去检查是否有任务需要去处理，在编写代码上无疑简单了很多，在实时性上也要比采用轮询的方式要好很多。而且现代的处理器一般都支持多个中断源，并且中断源中还设有不同的优先级，这样在中断中也可以实现嵌套，来保证高优先级事件一定能实时完成。

然而其存在的问题也是很明显的，虽然从main函数开始所有的任务都由用户来完成，获取了最大的自由度，但是这样一来，用户需要编写的代码量在一些对功耗或者是其他要求比较高的场合将会变的奇大无比。

优点：

• 控制过程直观

• 可以控制底层寄存器

• 性能较强（看编程人员能力）

缺点：

• 编程复杂度较高。

• 需要完成大量的非业务逻辑上的工作。

• 在对系统功耗等的控制上复杂度高。

  
  

2.2 操作系统实现多线程

在多线程的编程模型中，能够采用这种编程模型的处理器一般都是处理性能相对较强的处理器，如桌面电脑，服务器，手机等设备中。

在这种编程模型中，首先由操作系统虚拟出很多个程序运行空间，然后各个线程在调度器的调度之下按照时间片的方式运行，每个线程的运行执行都可以被认为是一个单独的程序，其自身完全的占用系统资源，一般用在对实时性和并发性的要求很高的情况下。其编程模型可用如下图所示的样子来进行概括。

在这种编程模型中，所有的线程在调度器的统一指挥下单独运行，每个线程都可以被调度器暂停或者恢复运行，而对于线程本身来说，其并不关心自己在何时被运行，在何时被中断，它唯一关心的是其自身是否能在规定的时间内正确的被执行完毕。

优点：

• 实时性强。

• 并发度高。

• 编程复杂度相对较低。

缺点：

• 需要操作系统

• 对处理器的要求高

• 功耗相对较高

• 需要较多的系统资源（RAM等）。

2.3 单线程异步编程

单线程的异步编程模型在浏览器中（Javascript）和图形化程序设计中采用的比较多。在这种编程模型中，所有的任务在一个轻量级的系统调控器的作用下，被安排成线性的方式去执行，当有事件发生的时候，相应的事件处理函数会被系统调控器自动的调用，当没有任何事件到达的时候，系统将由调控器接管。

因此，在采用单线程异步编程的时候，编程过程可以概括为以下2步：

1. 注册需要处理的各种事件。
   

2. 在相应的事件处理函数中编写事件到达后要完成的功能。

就本模型的功能上，介于上述的两种模型之间，对比循环加中断的方式其多了运行在后台的一个任务调度器，但是这个调控器的实现非常的简短，当且仅当在其他的任务执行完毕后主动让出处理器后才会去接管系统的运行，而在任务的处理过程中则是由事件处理函数本身来完全的掌控处理器。

采用这种编程模型来开发产品的时候，用户不需要关心，事件是如何被触发的，用户只需要使用正确的方式来在系统中注册相应的事件，然后编写好相应的事件处理过程就可以了。

比如在上图中，On_ready这个事件是在系统上电，准备就绪后被调用的。如果在这里需要处理一些事情，那么就在on_ready的函数中将想要实现的功能写出来就好了，比如在这里可以向系统注册一个事件，当100ms后执行一个time_task事件。然后当前on_ready函数执行完毕退出，系统交由调控器来控制，直到100ms后，调控器会产生一个time_task的事件，如果用户有编写好相应的事件处理函数的话，那么相应的处理过程就会被调用。

优点：

• 编程复杂度低。

• 用户可以专注业务逻辑部分。

• 开发周期短。

缺点：

• 一定的功能要受到框架的制约。

  
  

3. 最适合物联网的编程模型

通过对上面的几种编程模型的对比，可以得出以下结论。

对于物联网产品来说，其一般来说要求体积较小，对功耗敏感，要求能进行并发处理，但是事件的处理次数不会太频繁，同时对成本敏感，因此在处理器的选择上也无法选择性能很高的产品。

通过上述各种编程模型的对比，可以看出，基于对处理器的性能和功耗上的制约，采用操作系统实现的多线程方案，完全无法应用到物联网的产品中。而采用循环加中断的方式来实现物联网产品的设计的话，将要面临的难题是，在功耗等方面对程序员能力要求很高，代码的实现非常的复杂。最终得到的结果却是实时性能力一般，并发能力很低。而反观单线程异步编程，虽然其处理能力上确实不如基于操作系统实现的多线程方案，但是其表现能力则要比循环加中断的方式要优异很多。

由于单线程异步编程的调控器完成的功能较少，因此对处理器的要求不高，在功耗上，在调控器上已经实现了整个系统的节能方案，因此应用层无需理会功耗上的问题即可实现低功耗的产品。

同时，在物联网产品中，根据应用场合的不同，各个产品要完成的功能千差万别，且品种繁多，因此要求代码编写复杂度要尽可能的少。

基于以上的分析，采用单线程异步编程的方式，是目前物联网领域中最为合适的一种解决方案。