保護(hù)在我們眾多智能互聯(lián)設(shè)備和云之間收集和共享的敏感數(shù)據(jù)比以往任何時(shí)候都更加重要。工業(yè)傳感器、家用電器、可穿戴醫(yī)療設(shè)備等都利用數(shù)據(jù)，如果落入壞人之手，可能會(huì)導(dǎo)致嚴(yán)重后果。

傳輸層安全性 （TLS） 協(xié)議（以前稱為安全套接字層 （SSL））是用于保護(hù)傳輸中的數(shù)據(jù)的最常用協(xié)議。雖然它最初是為通過互聯(lián)網(wǎng)、計(jì)算機(jī)和網(wǎng)站之間的雙向安全通信而創(chuàng)建的，但現(xiàn)在 TLS 協(xié)議對于保護(hù)物聯(lián)網(wǎng)設(shè)備在互聯(lián)網(wǎng)上的通信、防止竊聽或篡改傳輸中的數(shù)據(jù)至關(guān)重要。該協(xié)議被認(rèn)為是健壯的，因?yàn)樗驯淮罅垦芯?、攻擊和修?fù)并被廣泛采用。為了確保TLS協(xié)議在設(shè)備端可以信任，必須將永遠(yuǎn)不得泄露或修改的密鑰，私鑰和證書存儲(chǔ)在設(shè)備中，并在協(xié)議執(zhí)行過程中使用。但是，由于物聯(lián)網(wǎng)設(shè)備部署在野外，這些安全資產(chǎn)可能會(huì)暴露給可能嘗試侵入性和非侵入性攻擊的攻擊者。在侵入性攻擊中，網(wǎng)絡(luò)犯罪分子打開設(shè)備的外殼以操縱其內(nèi)存內(nèi)容、更換固件或探測 PCB 走線。非侵入性類型通常通過通信端口執(zhí)行，針對設(shè)備固件中的邏輯錯(cuò)誤。如果沒有安全的IC伴侶，保護(hù)TLS實(shí)現(xiàn)就變得不可能。

本應(yīng)用筆記討論了一種低成本、低復(fù)雜度的解決方案，用于保護(hù)互聯(lián)嵌入式系統(tǒng)中的TLS實(shí)現(xiàn)，同時(shí)減輕器件應(yīng)用處理器的負(fù)擔(dān)。

概述：TLS 協(xié)議

TLS 發(fā)生在客戶端和服務(wù)器之間。在本應(yīng)用筆記中，“客戶端”是嵌入式系統(tǒng)（例如物聯(lián)網(wǎng)設(shè)備），“服務(wù)器”是云中的遠(yuǎn)程機(jī)器，可通過互聯(lián)網(wǎng)訪問。我

因此，讓我們想象一個(gè)帶有傳感器和執(zhí)行器的“客戶端”設(shè)備，它連接到“服務(wù)器”提供的 Web 服務(wù)。基于此方案，用戶可以使用智能手機(jī)查看傳感器數(shù)據(jù)，并通過服務(wù)器向設(shè)備發(fā)送命令。客戶端設(shè)備使用 TLS 向服務(wù)器報(bào)告數(shù)據(jù)或從服務(wù)器獲取命令。

TLS 協(xié)議有兩個(gè)主要階段：

建立（握手）

安全通信（通過身份驗(yàn)證和加密安全傳輸應(yīng)用程序數(shù)據(jù)）

建立（握手）階段

握手階段是安全通信配置的協(xié)商。該階段包括服務(wù)器和客戶端身份驗(yàn)證，以及共享密鑰的計(jì)算。此階段的四個(gè)步驟如下：

關(guān)于密碼套件的協(xié)議，該套件是將在以下后續(xù)階段中使用的加密算法的集合。服務(wù)器和客戶端決定使用哪組加密協(xié)議來協(xié)商共享密鑰和應(yīng)用程序通信的安全性。

客戶端對服務(wù)器的身份驗(yàn)證。在此階段，客戶端向服務(wù)器發(fā)送由隨機(jī)字節(jié)序列組成的消息。作為交換，服務(wù)器將自己的證書以及使用此隨機(jī)消息的數(shù)字簽名（使用服務(wù)器的私鑰計(jì)算）發(fā)送回客戶端。然后，客戶端使用服務(wù)器的證書驗(yàn)證郵件的簽名（在驗(yàn)證此證書之后）。

（可選）服務(wù)器對客戶端進(jìn)行身份驗(yàn)證。此步驟在嵌入式系統(tǒng)中很有用，其過程與步驟 2 相同。獨(dú)立客戶端設(shè)備不能“輸入其密碼”來向服務(wù)器進(jìn)行身份驗(yàn)證，這是網(wǎng)站上的常見做法。TLS 握手使用一個(gè)選項(xiàng)來解決此問題，該選項(xiàng)要求客戶端使用其客戶端私鑰提供數(shù)字簽名來證明其身份（遵循與步驟 2 中的服務(wù)器身份驗(yàn)證完全相同的方案）。

安全通信階段的共享通信密鑰（例如，AES密鑰）的協(xié)商。在此步驟中，可以使用復(fù)雜的基于公鑰的密鑰交換協(xié)議（如 ECDHE）交換密鑰。這些協(xié)議允許在客戶端和服務(wù)器端計(jì)算相同的密鑰或?qū)ΨQ密鑰，而無需實(shí)際傳輸它。然后，在下一階段使用密鑰交換中的密鑰對服務(wù)器和客戶端之間交換的消息進(jìn)行加密和簽名。這些密鑰用于所謂的對稱加密（相同的密鑰用于加密和解密，或兩端的簽名和驗(yàn)證，如基于 AES 的算法）。低內(nèi)存使用率和高性能要求推動(dòng)了使用對稱加密的需求。與AES相比，基于RSA或EC公鑰的算法將非常慢和/或缺乏資源。但是，分發(fā)用于安全通信的密鑰需要使用基于 RSA 或 EC 的算法進(jìn)行密鑰協(xié)商階段的復(fù)雜性。

預(yù)共享（秘密）密鑰交換算法提供了基于公鑰的密鑰交換算法的替代方法。在此方案中，在現(xiàn)場釋放設(shè)備之前，在服務(wù)器和設(shè)備中加載相同的密鑰。雖然此選項(xiàng)消除了實(shí)施 RSA 或 EC 加密的負(fù)擔(dān)，但它需要在設(shè)備和服務(wù)器上長期存儲(chǔ)相同的密鑰。然而，這種方法是有風(fēng)險(xiǎn)的，因?yàn)槿绻羞B接的對象共享相同的密鑰，則泄露單個(gè)密鑰會(huì)危及整個(gè)網(wǎng)絡(luò)。

安全通信階段

使用上述過程交換共享通信密鑰后，將建立安全的通信通道;兩個(gè)通信方可以開始交換應(yīng)用程序級數(shù)據(jù)（例如，HTTP請求/響應(yīng)）。TLS 協(xié)議層自動(dòng)加密和簽名發(fā)送的數(shù)據(jù)包，并在接收端解密和驗(yàn)證收到的數(shù)據(jù)包。該層使用基于密鑰的算法（例如用于加密的 AES-CBC、用于簽名的 AES-CMAC 或用于同時(shí)加密和簽名的較新的風(fēng)格（如 AES-CCM）來實(shí)現(xiàn)此目的。如果傳入消息已損壞，則 TLS 協(xié)議層將返回錯(cuò)誤。

通信結(jié)束后，共享通信密鑰（也稱為會(huì)話密鑰）將被丟棄。

紅綠燈的缺點(diǎn)

從軟件的角度來看，TLS協(xié)議可以使用現(xiàn)成的軟件庫（如mbedTLS，https://tls.mbed.org）輕松集成到任何應(yīng)用程序中。這種庫的軟件集成似乎很容易做到。畢竟，當(dāng)使用 TCP/IP 協(xié)議通過互聯(lián)網(wǎng)進(jìn)行通信時(shí)，應(yīng)用程序通常使用 POSIX 套接字 API 的“連接”、“讀取”和“寫入”功能。要使用 TLS，應(yīng)用程序只需在使用 mbedTLS 庫時(shí)將這些調(diào)用重定向到例如“mbedtls_ssl_connect”、“mbedtls_ssl_read”和“mbedtls_ssl_write”。應(yīng)用程序源代碼不需要包含實(shí)現(xiàn)TLS主要階段的所有幾率：“mbedtls_ssl_connect”自動(dòng)執(zhí)行身份驗(yàn)證和密鑰協(xié)商，“mbedtls_ssl_read”和“mbedtls_ssl_write”自動(dòng)將TLS保護(hù)（加密和簽名）添加到傳入和傳出的應(yīng)用程序數(shù)據(jù)傳輸（例如HTTP請求/響應(yīng)）。

此圖提供了 TLS 實(shí)現(xiàn)的粗略圖片。

盡管看起來很簡單，但將TLS庫集成到應(yīng)用程序及其配置（包括服務(wù)器上的配置）中也存在一些缺點(diǎn)。即使使用無錯(cuò)誤的TLS堆棧，軟件中TLS庫的集成和使用也可能有缺陷。

本應(yīng)用筆記的以下部分將探討客戶端（即嵌入式器件）TLS集成的常見弱點(diǎn)。

跳過的證書驗(yàn)證

應(yīng)用程序在使用 TLS 庫時(shí)經(jīng)?？吹降牡谝粋€(gè)問題與證書驗(yàn)證有關(guān)。

應(yīng)用程序的角色是強(qiáng)制驗(yàn)證服務(wù)器證書，因此 TLS 庫通常不會(huì)自動(dòng)執(zhí)行此操作。他們必須明確請求從 TLS 庫進(jìn)行驗(yàn)證。但是，如果沒有這個(gè)基本的驗(yàn)證步驟，通信可能會(huì)受到“中間人”攻擊。

圖2.中間人攻擊。第二

假設(shè)網(wǎng)絡(luò)流量被轉(zhuǎn)移到不是預(yù)期服務(wù)器的計(jì)算機(jī)。通過不驗(yàn)證對等證書，客戶端與攻擊者建立錯(cuò)誤可信的 TLS 通道。發(fā)生這種情況時(shí)，TLS 協(xié)議變得毫無用處，更糟糕的是，會(huì)給人一種錯(cuò)誤的安全印象。

弱密碼套件

TLS 故障可能源于服務(wù)器的配置。例如，可以將服務(wù)器配置為接受弱密碼套件。弱密碼套件通常使用已棄用或損壞的加密算法（如 RC4），這些算法太弱而無法抵御最先進(jìn)的攻擊。通常，從安全角度來看，TLS 協(xié)商階段會(huì)利用客戶端和服務(wù)器都支持的最強(qiáng)協(xié)議配置。但是，如果服務(wù)器支持過時(shí)的加密算法，則攻擊者可以降低服務(wù)器和客戶端之間交換的安全性，并訪問交換的數(shù)據(jù)。同樣，一些算法使用前向保密，這可以保護(hù)過去的會(huì)話免受將來密鑰或密碼的泄露。使用臨時(shí)Diffie-Hellman（DHE）或橢圓曲線變體（ECDHE）的密碼套件具有完美的前向保密性 - 這些是服務(wù)器應(yīng)該實(shí)現(xiàn)的密碼套件。有些選項(xiàng)沒有完全的前向保密。

易受攻擊的證書頒發(fā)機(jī)構(gòu)證書

有效驗(yàn)證服務(wù)器證書是抵御中間人攻擊不可或缺的一部分。存儲(chǔ)在嵌入式系統(tǒng)中的根證書驗(yàn)證服務(wù)器的證書。根證書通常在嵌入式設(shè)備制造過程中加載，屬于證書頒發(fā)機(jī)構(gòu)，該證書頒發(fā)機(jī)構(gòu)頒發(fā)設(shè)備和服務(wù)器證書，可以保證其完整性。如果此根證書被設(shè)備長期內(nèi)存中的流氓證書替換，則該證書可能會(huì)成為安全漏洞的受害者。發(fā)生這種情況時(shí)，攻擊者的服務(wù)器可以成功驗(yàn)證為有效服務(wù)器，因?yàn)閻阂夥?wù)器的證書將由惡意加載到客戶端設(shè)備的惡意根證書正確驗(yàn)證。此方案還需要某種形式的中間人攻擊;但是，這并不難做到。

公開的會(huì)話密鑰

會(huì)話密鑰是安全武器庫中的短期秘密武器：只要TLS安全通信通道，它們的有效性就會(huì)持續(xù)。一組會(huì)話密鑰不能用于猜測另一組會(huì)話密鑰。但是，如果這些密鑰泄露，這仍然會(huì)危及整個(gè) TLS 會(huì)話，無論是記錄的過去會(huì)話還是當(dāng)前正在運(yùn)行的會(huì)話。

客戶端身份驗(yàn)證密鑰泄露

TLS 協(xié)商階段可以包括客戶端向服務(wù)器進(jìn)行身份驗(yàn)證的步驟。如果客戶端公開其私鑰以向服務(wù)器進(jìn)行身份驗(yàn)證，則客戶端可由重復(fù)使用該密鑰的攻擊者模擬。

糟糕的加密實(shí)現(xiàn)和低質(zhì)量的隨機(jī)數(shù)

如果設(shè)備的長期記憶被轉(zhuǎn)儲(chǔ)，則此密鑰的暴露可能是“立即”的。這種暴露也可能是間接的，因?yàn)樗褂玫募用芩惴m然功能正確，但不能抵抗側(cè)信道攻擊。在側(cè)信道攻擊中，攻擊者可以通過測量設(shè)備的時(shí)序和/或功耗和/或電磁輻射來猜測私鑰或密鑰，當(dāng)它運(yùn)行涉及此類密鑰的加密算法時(shí)。

啟用更安全的客戶端 TLS 實(shí)現(xiàn)

有一組最低規(guī)則需要遵循，以維護(hù)真正安全的TLS方案，并減輕本應(yīng)用筆記中討論的陷阱：

CA 證書必須是真正不可變的。只有設(shè)備制造商或運(yùn)營商才能替換根證書。然后，挑戰(zhàn)在于保護(hù)對存儲(chǔ)證書的內(nèi)存的訪問，因?yàn)樽⑷肭度胧较到y(tǒng)應(yīng)用處理器中的任何軟件都可以修改內(nèi)存。

客戶端必須始終檢查服務(wù)器證書以避免 MITM 攻擊。

必須安全存儲(chǔ)客戶端的私有身份驗(yàn)證密鑰

必須使用安全的加密算法實(shí)現(xiàn)（并且能夠抵抗側(cè)信道分析）

TLS庫必須由應(yīng)用程序正確集成和配置，才能安全運(yùn)行

配套安全 IC 如何保護(hù) TLS 實(shí)施

客戶端的 TLS 握手階段涉及以下長期資產(chǎn)：

服務(wù)器證書

證書頒發(fā)機(jī)構(gòu)證書（根之一）

客戶端私鑰（如果使用）

預(yù)共享密鑰（如果使用）

使用安全I(xiàn)C，如MAXQ1061，通過設(shè)計(jì)防止上述漏洞，保護(hù)TLS實(shí)現(xiàn)，而不會(huì)給應(yīng)用處理器帶來任何額外的負(fù)擔(dān)。

MAXQ1061將CA根證書存儲(chǔ)在內(nèi)部非易失性存儲(chǔ)器中。這些證書只能替換為正確的基于公鑰的強(qiáng)身份驗(yàn)證。通常，遠(yuǎn)程管理員執(zhí)行這種強(qiáng)認(rèn)證，并且是唯一擁有私鑰以激活對MAXQ1061的訪問的實(shí)體。

MAXQ1061管理TLS握手階段，始終保證：

防止 MITM 攻擊。在使用之前，始終會(huì)驗(yàn)證服務(wù)器證書。MAXQ1061拒絕使用任意公鑰或證書進(jìn)行進(jìn)一步的簽名驗(yàn)證。在使用前，必須使用MAXQ1061中已有的有效證書對該公鑰進(jìn)行簽名。

由于它們是使用最先進(jìn)的加密技術(shù)（高質(zhì)量的隨機(jī)數(shù)，無側(cè)信道泄漏）計(jì)算的，因此會(huì)話密鑰不會(huì)泄漏

由于客戶端認(rèn)證是使用存儲(chǔ)在MAXQ1061長期存儲(chǔ)器中的私鑰執(zhí)行的，因此不能模擬客戶端。這些密鑰始終使用高質(zhì)量的隨機(jī)數(shù)生成器在內(nèi)部生成。根據(jù)設(shè)計(jì)，它們不能從IC中提取。

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

MAXQ1061僅在安全啟動(dòng)成功時(shí)允許客戶端認(rèn)證。只要應(yīng)用處理器的固件和配置尚未成功驗(yàn)證，此安全I(xiàn)C就可能使身份驗(yàn)證私鑰無法使用。使用此方法，客戶端設(shè)備只有在未被篡改的情況下才能作為正版設(shè)備進(jìn)行身份驗(yàn)證。此外，具有MAXQ1061的器件無法克隆：由于該安全I(xiàn)C包含唯一的私鑰，因此不可能偽造該安全I(xiàn)C。

Maxim提供的基于mbedTLS的略微修改的TLS堆棧允許應(yīng)用處理器利用MAXQ1061的上述特性，無需進(jìn)行重大的重新設(shè)計(jì)即可提供更高的安全級別。修改后的mbedTLS堆棧利用MAXQ1061進(jìn)行會(huì)話密鑰交換、服務(wù)器證書驗(yàn)證和客戶端認(rèn)證。安全通信本身可以由MAXQ1061本身或主應(yīng)用處理器進(jìn)行。

上述討論并不排除服務(wù)器端的任何弱點(diǎn)。不用說，必須遵循安全措施來保護(hù)服務(wù)器私鑰和證書鏈。

結(jié)論

保護(hù)嵌入式系統(tǒng)需要強(qiáng)大的軟件編碼和鎖定的系統(tǒng)門（物理和邏輯）。不要低估攻擊者也是值得的。

在安全的 IC 中存儲(chǔ)長期機(jī)密（如用于身份驗(yàn)證的私鑰）或證書等重要數(shù)據(jù)更安全、更容易。另一種方法是將這些資產(chǎn)存儲(chǔ)在通用應(yīng)用處理器中，但這些處理器通常通過設(shè)計(jì)提供許多調(diào)試功能，這些功能可以訪問其整個(gè)內(nèi)存內(nèi)容。將安全I(xiàn)C與應(yīng)用處理器一起使用的另一個(gè)好處是，兩個(gè)IC之間的物理隔離保證了應(yīng)用處理器中的軟件漏洞不會(huì)危及存儲(chǔ)在安全I(xiàn)C中的資產(chǎn)。

審核編輯：郭婷