前言

一個(gè)典型的物聯(lián)網(wǎng)產(chǎn)品

數(shù)據(jù)加密

證書

SSL/TLS

OpenSSL

OpenSSH又是什么?

總結(jié)

前言

在一個(gè)物聯(lián)網(wǎng)系統(tǒng)中,終端設(shè)備在連接云平臺(tái)(服務(wù)器)的時(shí)候,云平臺(tái)需要對(duì)設(shè)備的身份進(jìn)行驗(yàn)證,驗(yàn)證這是一個(gè)合法的設(shè)備之后才允許接入。這看似很簡(jiǎn)單的一句話,背后包含了很多相關(guān)的概念,例如:加密、證書、證書標(biāo)準(zhǔn)、簽名、認(rèn)證機(jī)構(gòu)、SSL/TLS、OpenSSL、握手等一堆容易混淆的概念。

之前我在做智能家居項(xiàng)目時(shí),每次遇到證書以及加密的問題時(shí),都是滿大街的查資料,但是由于每次都是解決問題之后就停止下來(lái),沒有進(jìn)行完整、系統(tǒng)的梳理,因此對(duì)這些概念始終感覺自己都理解了,但是又說(shuō)不出所以然來(lái)。

這篇文章我們就把這些概念以及相關(guān)的使用步驟進(jìn)行梳理,就像聯(lián)想記憶一樣,很多分散的東西總是記不住,但是如果把這些東西按照特定的關(guān)系組織在一起,那么記憶起來(lái)就非常容易了。

做個(gè)小游戲:在1分鐘內(nèi)記下這十個(gè)東西:茶杯、猴子、玻璃、垃圾桶、魚竿、鳥窩、和尚、汽車、醫(yī)院、飲水機(jī)。這里可以暫停一下,看看自己的記憶力是不是不如以前了。

我們?cè)贀Q個(gè)記憶方法,把這十個(gè)東西以任意荒誕的邏輯聯(lián)系在一起,比如:一只猴子,左手拿著茶杯,右手拿著玻璃,往垃圾桶走去。在垃圾桶旁邊,看到一只魚竿,于是它就用魚竿去戳樹上的鳥窩。鳥窩里掉下來(lái)一個(gè)鳥蛋,正好砸在了和尚的頭上,流血了,趕緊攔下一輛汽車去醫(yī)院。到了醫(yī)院,和尚失血太多口渴了,正好看到一臺(tái)飲水機(jī)。

把這個(gè)荒誕的故事想幾遍,然后再試著把這十個(gè)東西說(shuō)出來(lái),這回是不是感覺很容易?而且連順序都不會(huì)記錯(cuò)!這就是聯(lián)想記憶的魔力。

那么學(xué)習(xí)知識(shí)也是這個(gè)道理:分散的知識(shí)是記不住的,只有梳理成體系,把相互之間的聯(lián)系和脈絡(luò)掌握了,再去理解這些分散的點(diǎn)就很容易記住了。這里的關(guān)鍵就是把這些知識(shí)點(diǎn)相互之間的關(guān)系掌握了,就像一張網(wǎng)一樣,隨便把一個(gè)知識(shí)點(diǎn)拎出來(lái),都可以根據(jù)這張網(wǎng)把其他的知識(shí)點(diǎn)聯(lián)想起來(lái)。

這篇文章的內(nèi)容包括:

物聯(lián)網(wǎng)云平臺(tái),是如何驗(yàn)證設(shè)備端的合法性?

SSL/TLS是什么?有什么作用?在哪些場(chǎng)合下使用?

OpenSSL是什么?它與SSL是什么關(guān)系?

OpenSSH又是什么?它與OpenSSL又有什么區(qū)別?

HTTPS中是如何利用SSL來(lái)交換秘鑰的?握手步驟是什么?

證書是什么?有什么作用?在哪些場(chǎng)合下使用?

證書是如何得到的?它的標(biāo)準(zhǔn)格式是什么?包含哪些內(nèi)容?

認(rèn)證機(jī)構(gòu)是什么?什么是鏈?zhǔn)阶C書?

證書與SSL有什么關(guān)系?

簽名是什么意思?與加密是什么關(guān)系?

什么是單向認(rèn)證?雙向認(rèn)證?

另外補(bǔ)充一點(diǎn):這篇文章只描述“是什么”,而不會(huì)描述“為什么”。“為什么”的事情留給那些數(shù)學(xué)家、密碼學(xué)家來(lái)搞定就可以了。

一個(gè)典型的物聯(lián)網(wǎng)產(chǎn)品

在實(shí)際的項(xiàng)目中,如果用到云平臺(tái),一般來(lái)說(shuō)選擇性就那么幾個(gè):國(guó)外就用亞馬遜,國(guó)內(nèi)就用阿里云,最近也碰到一些項(xiàng)目使用華為云。這里就以之前做過(guò)的一個(gè)空氣凈化器項(xiàng)目來(lái)舉例:

首先,亞馬遜提供了一套SDK,這個(gè)SDK中包含了一組API函數(shù)供應(yīng)用程序調(diào)用,向云平臺(tái)進(jìn)行安全連接、收發(fā)數(shù)據(jù)。在調(diào)用API函數(shù)的時(shí)候,必須提供一些必要的設(shè)備信息,這其中最重要的就是設(shè)備證書文件,也就是說(shuō),證書必須要預(yù)先存儲(chǔ)在設(shè)備的文件系統(tǒng)中。

那么,證書是在什么時(shí)候被放到空氣凈化器設(shè)備中的?當(dāng)然是生產(chǎn)階段,看一下這個(gè)流程:

生產(chǎn)工具軟件運(yùn)行在產(chǎn)線的PC機(jī)上,通過(guò)串口連接到空氣凈化器設(shè)備,從設(shè)備中讀取唯一識(shí)別碼(例如:MAC地址);生產(chǎn)工具軟件上傳必要的信息(廠商基本信息、廠商秘鑰、空凈設(shè)備的唯一識(shí)別碼)給AWS云平臺(tái),申請(qǐng)得到一個(gè)證書文件;AWS云平臺(tái)根據(jù)廠商預(yù)先在平臺(tái)上的部署程序,產(chǎn)生一個(gè)證書文件,返回給生產(chǎn)工具軟件;生產(chǎn)工具軟件把證書文件通過(guò)串口發(fā)送給空氣凈化器設(shè)備;空氣凈化器設(shè)備接收到的證書文件之后,存儲(chǔ)到本地的文件系統(tǒng)中。

以上這個(gè)流程是在設(shè)備生產(chǎn)環(huán)節(jié)完成的,這里的描述還是屬于粗線條的,其他一些重要的信息沒有列出來(lái),比如:AWS后臺(tái)如何產(chǎn)生證書、在連接階段后臺(tái)是如何通過(guò)證書來(lái)驗(yàn)證設(shè)備的合法性的、廠商的秘鑰是如何工作的等等,這些問題等到這邊文章的末尾就自然明白了。

下面,就按照這些概念之間的相互關(guān)系來(lái)一步一步的梳理,每一個(gè)概念是按照相互之間的關(guān)系來(lái)逐步引入的,因此建議按照順序來(lái)理解。

數(shù)據(jù)加密 明文傳輸?shù)娜秉c(diǎn)

我們知道,client端與server端之間傳輸數(shù)據(jù),要么是明文傳輸、要么是加密傳輸。明文傳輸?shù)娜秉c(diǎn)顯而易見:

數(shù)據(jù)容易比第三方截獲;

第三方可以篡改數(shù)據(jù);

第三方可能會(huì)冒充server與你進(jìn)行通信。

總之一句話:明文通信就像裸奔一樣,任何東西都被別人看的一清二楚,惡意的第三方很容易利用明文通信來(lái)做一些違法的事情。

所以,最好還是穿上衣服,最好還是帶密碼鎖的,這樣別人就看不到了!這就是加密傳輸。

加密傳輸

client端對(duì)傳輸?shù)男畔⑦M(jìn)行加密,server端接收到密文后再進(jìn)行解密。例如上圖中:

client想發(fā)送字符串"hello",那么就先加密成"ifmmp",然后發(fā)送出去;
server接收到"ifmmp",進(jìn)行解密,得到"hello"。

但是示例中的加密方式太弱智了,稍微研究下就會(huì)搞明白,這里的加密方式就是把明文字符串中的每一個(gè)字符變成ascII碼表中的下一個(gè)字。server在解密時(shí)操作相反:把每一個(gè)字符變成ascII碼表中的前一個(gè)字符即可,只要client和server事先商量好這樣的加密和解密算法就可以通信了。

但是,這樣的加密方式太簡(jiǎn)單了,惡意的第三方不會(huì)吹灰之力就可以破解出來(lái),因此client與server之間需要更加復(fù)雜的加密算法,這就是SSL要解決的問題,這部分內(nèi)容稍后再表。

加密方式

根據(jù)是否可以把密文還原成明文,加密方式分為兩類:

可逆加密;
不可逆加密。

剛才描述的加密、解密過(guò)程("hello"->"ifmmp"->"hello")是屬于可逆加密,也就是說(shuō)可以把密文還原成明文,主要應(yīng)用在通信場(chǎng)景中。如果一個(gè)密文不能還原成明文,就稱為不可逆加密,不可逆加密也非常重要。

可逆加密

剛才已經(jīng)說(shuō)到,可逆加密就是可以把密文還原成明文,只要client端和server端商量好加密算法(例如剛才所說(shuō)的利用ascII表的下一個(gè)字符)就可以達(dá)到目的,也就是說(shuō):client端的加密算法和server端的解密算法是一樣的,當(dāng)然了這里的算法太簡(jiǎn)單。

我們可以稍微復(fù)雜一點(diǎn)點(diǎn),先定義一個(gè)固定的字符串“258”,然后把明文"hello"中的每一個(gè)字符,用固定的字符串進(jìn)行計(jì)算:先加2,再減5,最后加8,得到加密后的字符串"mjqqt",server接收到之后再執(zhí)行相反操作就解密得到明文“hello”。從算法角度看,這兩個(gè)加密方式是一樣的,但是第二種算法利用了一個(gè)獨(dú)立的、固定的字符串“258”,這個(gè)字符串就叫做秘鑰,當(dāng)然,實(shí)際通信中使用的秘鑰更復(fù)雜。通信雙方是通過(guò)算法+秘鑰的方式來(lái)進(jìn)行加密和解密。而且,通信雙方使用的秘鑰是相同的,這就叫做對(duì)稱加密。

既然存在對(duì)稱加密,那肯定就存在非對(duì)稱加密,也就是說(shuō),根據(jù)通信雙方使用的秘鑰是否相同,可逆加密分為2種:

對(duì)稱加密;非對(duì)稱加密。

對(duì)稱加密常用算法有:DES、AES;非對(duì)稱加密常用算法有:RSA、DH、ECC。

對(duì)稱加密的特點(diǎn):

計(jì)算速度快;加密強(qiáng)度高;能處理的數(shù)據(jù)量大。

非對(duì)稱加密的特點(diǎn):

效率低;能處理的數(shù)據(jù)量大小有限制。

既然非對(duì)稱加密的缺點(diǎn)這么明顯,那么它有什么作用呢?

回到剛才的通信示例場(chǎng)景中:client與server需要使用同一個(gè)秘鑰“258”,那么它們雙方應(yīng)該如何協(xié)商得到這個(gè)對(duì)稱秘鑰呢?難道是使用固定的秘鑰嗎?顯然這個(gè)答案不太可能,需要通信的設(shè)備那么多,不可能像網(wǎng)卡的MAC地址那樣預(yù)先分配,而且秘鑰很容易泄漏。因此,這個(gè)對(duì)稱秘鑰一般都是在通信的剛開始的握手階段,由client與server動(dòng)態(tài)的協(xié)商得到的。在這個(gè)協(xié)商的過(guò)程中,為了防止協(xié)商內(nèi)容被第三方截獲,就需要使用非對(duì)稱加密來(lái)保證握手階段的數(shù)據(jù)安全性。

因?yàn)槲帐謹(jǐn)?shù)據(jù)只發(fā)生在通信的剛開始階段,即使效率低一點(diǎn)也沒關(guān)系,安全比效率更重要。

一句話:非對(duì)稱加密在通信初始階段的協(xié)商過(guò)程中使用,用來(lái)得到一個(gè)對(duì)稱秘鑰,這個(gè)協(xié)商過(guò)程就叫做握手,在后面的HTTPS通信過(guò)程中,我們?cè)僭敿?xì)看一下握手過(guò)程。