使用安全配套IC保護TLS實現(xiàn)

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

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

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

概述：TLS 協(xié)議

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

因此，讓我們想象一個帶有傳感器和執(zhí)行器的“客戶端”設備，它連接到“服務器”提供的 Web 服務?；诖朔桨福脩艨梢允褂?a target="_blank">智能手機查看傳感器數(shù)據(jù)，并通過服務器向設備發(fā)送命令?？蛻舳嗽O備使用 TLS 向服務器報告數(shù)據(jù)或從服務器獲取命令。

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

建立（握手）

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

建立（握手）階段

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

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

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

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

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

預共享（秘密）密鑰交換算法提供了基于公鑰的密鑰交換算法的替代方法。在此方案中，在現(xiàn)場釋放設備之前，在服務器和設備中加載相同的密鑰。雖然此選項消除了實施 RSA 或 EC 加密的負擔，但它需要在設備和服務器上長期存儲相同的密鑰。然而，這種方法是有風險的，因為如果所有連接的對象共享相同的密鑰，則泄露單個密鑰會危及整個網(wǎng)絡。

安全通信階段

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

通信結束后，共享通信密鑰（也稱為會話密鑰）將被丟棄。

紅綠燈的缺點

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

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

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

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

跳過的證書驗證

應用程序在使用 TLS 庫時經(jīng)常看到的第一個問題與證書驗證有關。

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

圖2.中間人攻擊。第二

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

弱密碼套件

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

易受攻擊的證書頒發(fā)機構證書

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

公開的會話密鑰

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

客戶端身份驗證密鑰泄露

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

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

如果設備的長期記憶被轉儲，則此密鑰的暴露可能是“立即”的。這種暴露也可能是間接的，因為所使用的加密算法雖然功能正確，但不能抵抗側信道攻擊。在側信道攻擊中，攻擊者可以通過測量設備的時序和/或功耗和/或電磁輻射來猜測私鑰或密鑰，當它運行涉及此類密鑰的加密算法時。

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

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

CA 證書必須是真正不可變的。只有設備制造商或運營商才能替換根證書。然后，挑戰(zhàn)在于保護對存儲證書的內(nèi)存的訪問，因為注入嵌入式系統(tǒng)應用處理器中的任何軟件都可以修改內(nèi)存。

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

必須安全存儲客戶端的私有身份驗證密鑰

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

TLS庫必須由應用程序正確集成和配置，才能安全運行

配套安全 IC 如何保護 TLS 實施

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

服務器證書

證書頒發(fā)機構證書（根之一）

客戶端私鑰（如果使用）

預共享密鑰（如果使用）

使用安全IC，如MAXQ1061，通過設計防止上述漏洞，保護TLS實現(xiàn)，而不會給應用處理器帶來任何額外的負擔。

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

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

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

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

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

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

MAXQ1061僅在安全啟動成功時允許客戶端認證。只要應用處理器的固件和配置尚未成功驗證，此安全IC就可能使身份驗證私鑰無法使用。使用此方法，客戶端設備只有在未被篡改的情況下才能作為正版設備進行身份驗證。此外，具有MAXQ1061的器件無法克?。河捎谠摪踩獻C包含唯一的私鑰，因此不可能偽造該安全IC。

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

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

結論

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

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

審核編輯：郭婷