前言

一个典型的物联网产品

数据加密

证书

SSL/TLS

OpenSSL

OpenSSH又是什么?

总结

前言

在一个物联网系统中,终端设备在连接云平台(服务器)的时候,云平台需要对设备的身份进行验证,验证这是一个合法的设备之后才允许接入。这看似很简单的一句话,背后包含了很多相关的概念,例如:加密、证书、证书标准、签名、认证机构、SSL/TLS、OpenSSL、握手等一堆容易混淆的概念。

之前我在做智能家居项目时,每次遇到证书以及加密的问题时,都是满大街的查资料,但是由于每次都是解决问题之后就停止下来,没有进行完整、系统的梳理,因此对这些概念始终感觉自己都理解了,但是又说不出所以然来。

这篇文章我们就把这些概念以及相关的使用步骤进行梳理,就像联想记忆一样,很多分散的东西总是记不住,但是如果把这些东西按照特定的关系组织在一起,那么记忆起来就非常容易了。

做个小游戏:在1分钟内记下这十个东西:茶杯、猴子、玻璃、垃圾桶、鱼竿、鸟窝、和尚、汽车、医院、饮水机。这里可以暂停一下,看看自己的记忆力是不是不如以前了。

我们再换个记忆方法,把这十个东西以任意荒诞的逻辑联系在一起,比如:一只猴子,左手拿着茶杯,右手拿着玻璃,往垃圾桶走去。在垃圾桶旁边,看到一只鱼竿,于是它就用鱼竿去戳树上的鸟窝。鸟窝里掉下来一个鸟蛋,正好砸在了和尚的头上,流血了,赶紧拦下一辆汽车去医院。到了医院,和尚失血太多口渴了,正好看到一台饮水机。

把这个荒诞的故事想几遍,然后再试着把这十个东西说出来,这回是不是感觉很容易?而且连顺序都不会记错!这就是联想记忆的魔力。

那么学习知识也是这个道理:分散的知识是记不住的,只有梳理成体系,把相互之间的联系和脉络掌握了,再去理解这些分散的点就很容易记住了。这里的关键就是把这些知识点相互之间的关系掌握了,就像一张网一样,随便把一个知识点拎出来,都可以根据这张网把其他的知识点联想起来。

这篇文章的内容包括:

物联网云平台,是如何验证设备端的合法性?

SSL/TLS是什么?有什么作用?在哪些场合下使用?

OpenSSL是什么?它与SSL是什么关系?

OpenSSH又是什么?它与OpenSSL又有什么区别?

HTTPS中是如何利用SSL来交换秘钥的?握手步骤是什么?

证书是什么?有什么作用?在哪些场合下使用?

证书是如何得到的?它的标准格式是什么?包含哪些内容?

认证机构是什么?什么是链式证书?

证书与SSL有什么关系?

签名是什么意思?与加密是什么关系?

什么是单向认证?双向认证?

另外补充一点:这篇文章只描述“是什么”,而不会描述“为什么”。“为什么”的事情留给那些数学家、密码学家来搞定就可以了。

一个典型的物联网产品

在实际的项目中,如果用到云平台,一般来说选择性就那么几个:国外就用亚马逊,国内就用阿里云,最近也碰到一些项目使用华为云。这里就以之前做过的一个空气净化器项目来举例:

首先,亚马逊提供了一套SDK,这个SDK中包含了一组API函数供应用程序调用,向云平台进行安全连接、收发数据。在调用API函数的时候,必须提供一些必要的设备信息,这其中最重要的就是设备证书文件,也就是说,证书必须要预先存储在设备的文件系统中。

那么,证书是在什么时候被放到空气净化器设备中的?当然是生产阶段,看一下这个流程:

生产工具软件运行在产线的PC机上,通过串口连接到空气净化器设备,从设备中读取唯一识别码(例如:MAC地址);生产工具软件上传必要的信息(厂商基本信息、厂商秘钥、空净设备的唯一识别码)给AWS云平台,申请得到一个证书文件;AWS云平台根据厂商预先在平台上的部署程序,产生一个证书文件,返回给生产工具软件;生产工具软件把证书文件通过串口发送给空气净化器设备;空气净化器设备接收到的证书文件之后,存储到本地的文件系统中。

以上这个流程是在设备生产环节完成的,这里的描述还是属于粗线条的,其他一些重要的信息没有列出来,比如:AWS后台如何产生证书、在连接阶段后台是如何通过证书来验证设备的合法性的、厂商的秘钥是如何工作的等等,这些问题等到这边文章的末尾就自然明白了。

下面,就按照这些概念之间的相互关系来一步一步的梳理,每一个概念是按照相互之间的关系来逐步引入的,因此建议按照顺序来理解。

数据加密 明文传输的缺点

我们知道,client端与server端之间传输数据,要么是明文传输、要么是加密传输。明文传输的缺点显而易见:

数据容易比第三方截获;

第三方可以篡改数据;

第三方可能会冒充server与你进行通信。

总之一句话:明文通信就像裸奔一样,任何东西都被别人看的一清二楚,恶意的第三方很容易利用明文通信来做一些违法的事情。

所以,最好还是穿上衣服,最好还是带密码锁的,这样别人就看不到了!这就是加密传输。

加密传输

client端对传输的信息进行加密,server端接收到密文后再进行解密。例如上图中:

client想发送字符串"hello",那么就先加密成"ifmmp",然后发送出去;
server接收到"ifmmp",进行解密,得到"hello"。

但是示例中的加密方式太弱智了,稍微研究下就会搞明白,这里的加密方式就是把明文字符串中的每一个字符变成ascII码表中的下一个字。server在解密时操作相反:把每一个字符变成ascII码表中的前一个字符即可,只要client和server事先商量好这样的加密和解密算法就可以通信了。

但是,这样的加密方式太简单了,恶意的第三方不会吹灰之力就可以破解出来,因此client与server之间需要更加复杂的加密算法,这就是SSL要解决的问题,这部分内容稍后再表。

加密方式

根据是否可以把密文还原成明文,加密方式分为两类:

可逆加密;
不可逆加密。

刚才描述的加密、解密过程("hello"->"ifmmp"->"hello")是属于可逆加密,也就是说可以把密文还原成明文,主要应用在通信场景中。如果一个密文不能还原成明文,就称为不可逆加密,不可逆加密也非常重要。

可逆加密

刚才已经说到,可逆加密就是可以把密文还原成明文,只要client端和server端商量好加密算法(例如刚才所说的利用ascII表的下一个字符)就可以达到目的,也就是说:client端的加密算法和server端的解密算法是一样的,当然了这里的算法太简单。

我们可以稍微复杂一点点,先定义一个固定的字符串“258”,然后把明文"hello"中的每一个字符,用固定的字符串进行计算:先加2,再减5,最后加8,得到加密后的字符串"mjqqt",server接收到之后再执行相反操作就解密得到明文“hello”。从算法角度看,这两个加密方式是一样的,但是第二种算法利用了一个独立的、固定的字符串“258”,这个字符串就叫做秘钥,当然,实际通信中使用的秘钥更复杂。通信双方是通过算法+秘钥的方式来进行加密和解密。而且,通信双方使用的秘钥是相同的,这就叫做对称加密。

既然存在对称加密,那肯定就存在非对称加密,也就是说,根据通信双方使用的秘钥是否相同,可逆加密分为2种:

对称加密;非对称加密。

对称加密常用算法有:DES、AES;非对称加密常用算法有:RSA、DH、ECC。

对称加密的特点:

计算速度快;加密强度高;能处理的数据量大。

非对称加密的特点:

效率低;能处理的数据量大小有限制。

既然非对称加密的缺点这么明显,那么它有什么作用呢?

回到刚才的通信示例场景中:client与server需要使用同一个秘钥“258”,那么它们双方应该如何协商得到这个对称秘钥呢?难道是使用固定的秘钥吗?显然这个答案不太可能,需要通信的设备那么多,不可能像网卡的MAC地址那样预先分配,而且秘钥很容易泄漏。因此,这个对称秘钥一般都是在通信的刚开始的握手阶段,由client与server动态的协商得到的。在这个协商的过程中,为了防止协商内容被第三方截获,就需要使用非对称加密来保证握手阶段的数据安全性。

因为握手数据只发生在通信的刚开始阶段,即使效率低一点也没关系,安全比效率更重要。

一句话:非对称加密在通信初始阶段的协商过程中使用,用来得到一个对称秘钥,这个协商过程就叫做握手,在后面的HTTPS通信过程中,我们再详细看一下握手过程。