聊聊Mbedtls 基礎及其應用

 

1、引言

1.1 為什麼要加密

網際網路是開放環境，通信雙方都是未知身份，為通信雙方的有效信息不被第三方竊聽、篡改或者被冒充身份進行通信，需要為信息加上保護措施。也就是對所有信息都進行加密，避免被第三方竊聽;採用校驗機制，可以識別出信息是否被篡改，配備身份認證防止被冒充身份。網際網路的通信安全，就是建立在SSL/TLS協議之上。

1.2 SSL/TLS協議的歷史

1996年，在前面的基礎上，SSL 3.0版問世並得到大規模應用;

1999年，網際網路標準化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版，也稱為SSL 3.1;SSL和TLS指的是同一套加密協議，只是不同時期的名字差異。

2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。

一般推薦使用TLS 1.2，主流的瀏覽器都支持。

2、SSL/TLS演化

熟悉一套技術的演進步驟，比直接看最新版本，更容量理解。

2.1 明文時代

小帥向小美發送信息，直接以明文形式發送。

缺點顯而易見，第三方小黑很容易就竊取到信息，也可以進行篡改後發給小美，而且小美收到後並不知情，以為是小帥發來的。

2.2 對稱加密時代

小帥和小美保存一份相同的秘鑰，小帥發出的信息先經過加密，小美收到後使用同樣的密碼進行解密。這種加密和解密使用同一個密鑰的算法稱為對稱加密算法。

短期內小黑對加密數據無能為力，但是每次變更秘鑰需要事先協商，如果協商出問題，小帥告知小美新秘鑰時，秘鑰被小黑截取，那後續的密文對小黑來說，他也可以解密成明文。也可以篡改明文信息後，再使用同樣的秘鑰加密後發給小美。

2.3 非對稱加密時代

既然進行秘鑰交換存在風險，小帥和小美採用非對稱加密算法。雙方各自保存私鑰、公鑰，兩者配對，私鑰自己保存，公鑰由私鑰運算生成發給對方，不能由公鑰反推算出私鑰;但是使用公鑰加密的密文，卻可以使用私鑰解密;使用私鑰籤名，使用公鑰驗證;這種加密和解密使用不同的密鑰的算法成為非對稱加密算法。

通信前，雙發先將自己的公鑰發給對方，私鑰保密;小帥先使用小美提供的公鑰加密數據，同時也使用自己的私鑰進行籤名標記，一起打包後發給小美，小美使用自己的私鑰進行解密，再使用小帥的公鑰進行驗證，確認收到的信息是否來自小帥。

這種形式的加密通信，協商傳輸的是公鑰，即使被小黑截取，他也不能解密後續的信息，因為解密得使用私鑰。

但是百密一疏，如果小黑子在最初交互公鑰時，截取公鑰，把小帥發給小美的公鑰截取，把自己的假公鑰發給小美;截取小美發出的數據，小黑用自己的私鑰解密，然後再使用自己的私鑰加密後發給小帥。

整了這麼複雜的一套加密協議，結果還是存在隱患。

2.4 公證時代

問題就出在公鑰交換，小美收到一份公鑰，如何證明這公鑰確實是小帥發出的?譬如買房，只有房管局確認蓋章導入系統的房產證，才是真的房產證，才能放心進行交易。通過CA(Certificate Authority)證書頒發機構來保證公鑰的真實性，為公鑰的真實性進行擔保公證。

CA也是基於非對稱加密算法，小帥先先把自己的公鑰交給CA，CA用自己的私鑰加密這些數據，加密完的數據稱為小帥的數字證書，先前小帥發給小美的公鑰，改為發送CA加密之後的數字證書。小美收到以後，通過CA發布的CA證書(包含了CA的公鑰)，來解密小帥的數字證書，從而獲得小帥的公鑰。

問題是小美怎麼確保CA證書不是小黑偽造的?CA證書是提前預置在瀏覽器或作業系統，或者嵌入式設備內，不需要聯網獲取，自然也不存在劫持篡改的問題。

雖然小黑還是可以攔截帶公鑰的數字籤名證書，可以用CA公鑰解密看到內容;但是他沒CA的秘鑰，無法偽造出正確的數字籤名證書，也就是小帥的真實公鑰小黑可見不可改，改了小美會發現異常，但只有公鑰並沒什麼價值。

2.5 TLS協議時代

公證時代的解決方案就是SSL/TLS協議加密通信基礎。因為使用非對稱加密算法比對稱加密算法要複雜，消耗運算資源，為考慮效率，非對稱加密只會用來傳遞一條信息，即對稱加密的密鑰。對稱加密的密鑰確定，後續有效信息使用對稱加密算法進行網絡傳輸。既保證了網絡通信的安全性，又不影響效率。

SSL/TLS協議的基本過程：

1、通過CA體系交換公鑰

2、使用非對稱加密算法，交換用於對稱加密的密鑰

3、有效數據使用對稱加密算法，進行密文傳輸

前兩步又稱為"握手階段"(handshake),是SSL/TLS加密通信的基礎。

2.6 TLS的應用

在SSL/TLS出現之前，很多應用層協議(http、ftp、smtp等)都存在著網絡安全問題。最常見的http協議，在傳輸過程中使用的是明文信息，傳輸報文一旦被截獲便會洩露傳輸內容;傳輸過程中報文如果被篡改，對方無法輕易發現;無法保證消息交換的對端身份的可靠性。為了解決此類安全問題，在應用層和傳輸層之間加入了SSL/TLS協議，升級為https。SSL/TLS目前已經廣泛用於數據安全協議。關於SSL/TLS有很多開源軟體包，如openSSL,mbedtls等。openSSL功能更強大，mbedtls小巧更適合嵌入式設備。

3、mbedtls

隨著物聯網的發展，設備節點的安全問題也越來越重要，相比網際網路的openSSL，物聯網的嵌入式設備適合小巧靈活的MbedTLS，曾用名PolarSSL，可以根據需求進行配置，降低對硬體資源的消耗。mbedtls內置了非常多的加密解密，散列算法源碼，即使不使用tls加密，也從裡面挖掘各種算法，諸如AES/RSA/MD5等。但是openSSL功能更強大，

mbedtls是一款採用Apache 2.0許可證協議開源軟體加密庫，使用標準C語言編寫;獨立的模塊設計，降低模塊之間的耦合度。從功能上看，主要包括加密庫、X509證書、SSL/TLS協議三部分。

3.1 軟體包

進入https://tls.mbed.org/[1]，點擊download，在https://github.com/ARMmbed/mbedtls[2]下載源碼。

Git下載界面有說明編譯方式

• Compiling
• There are currently three active build systems used within Mbed TLS releases:
• GNU Make
• CMake
• Microsoft Visual Studio (Microsoft Visual Studio 2013 or later)

目前個人接觸的晶片SDK內置mbedtls有v2.4.0，v2.4.2和v2.14.1三種，將git版本切到v2.14.1，最後提交是2018年。前期先在電腦模擬測試，選擇Visual Studio 2013。

3.2 軟體結構

mbedtls源碼結構如下圖

mbedtls\include\mbedtls下面，可以version.h查看版本信息，重點是config.h配置，mbedtls是一套加密集合，實際項目使用中僅需選擇少部分即可，配置功能宏裁剪代碼，簡化運算，畢竟mbedtls跑一遍，一般的arm單片機不一定扛得住。

programs\ssl下是參考範例，TLS的客戶端和服務端範例，以及UDP版本的DTLS。嵌入式設備以客戶端應用居多，主要參考ssl_client2.c裡面很多配置參數可選，也可以針對應用替換ssl_client1.c。

測試TLS客戶端首先要準備3個文件，CA證書，客戶端公鑰數字證書以及私鑰。一般情況下命名後綴如下：

.crt CA證書 .pem 公鑰，經CA加密後的公鑰，也稱為數字證書 .key 私鑰 有時crt和pem混用，其本質都是CA公鑰加密後的文件

如果沒有伺服器聯調，也可以使用自身的ssl_server2.c做伺服器。

3.3 demo流程分析

ssl_client2.c範例都在main函數，其大體流程如下：

• 1、先加載各種證書、秘鑰，配置opt結構體成員初始化，如TLS版本，加密套件類型等
• 2、然後開始連接伺服器 mbedtls_net_connect
• 3、初始化tls參數 mbedtls_ssl_config_defaults，設置網絡收發回調函數等
• 4、SSL/TLS握手流程，過程比較複雜，簡化就是通信雙方校驗對方身份，獲取對方的公鑰，確認加密方式，後續數據進行加密或解密做準備 mbedtls_ssl_handshake
• 5、校驗服務端返回的證書 mbedtls_ssl_get_verify_result
• 6、如果前面流程順暢，就可以使用mbedtls_ssl_write，mbedtls_ssl_read收發數據了
• 7、測試結束後的清理工作
• 8、與標準socket編程對比，接口存在一定的對應關係：

4、mbedtls移植

先在電腦端模擬測試，確定參數，簡化範例裡的賦值，因為實際項目參數不會經常變更，優化代碼，尤其是秘鑰加載，嵌入式都是以數組保存文件內容，而不會使用文件形式加載。另外結合加密等級，確定加密套件類型。

模擬測試正常後，再移植到ARM平臺，主要改動涉及網絡連接、內存管理和定時器三個方面。

4.1 網絡接口

mbedtls默認的網絡接口mbedtls/library/net_socket.c，可以在windows下運行，特別注意，默認的socket操作都是阻塞模式;一般不適合ARM平臺，關閉MBEDTLS_NET_C，結合硬體平臺重新實現網絡接口。主要包括以下函數：

1. void mbedtls_net_init( mbedtls_net_context *ctx ); 
2. int mbedtls_net_connect( mbedtls_net_context *ctx, const char *host, const char *port, int proto ); 
3. int mbedtls_net_recv( void *ctx, unsigned char *buf, size_t len ); 
4. int mbedtls_net_recv_timeout( void *ctx, unsigned char *buf, size_t len, uint32_t timeout ); 
5. int mbedtls_net_send( void *ctx, const unsigned char *buf, size_t len ); 
6. void mbedtls_net_free( mbedtls_net_context *ctx ); 

若需要DUP版本的DTLS，還需要實現該文件下另外幾個接口，具體流程參考dtls_client.c。

自定義實現的網絡收發接口，需要註冊mbedtls_ssl_set_bio告知底層。

1. mbedtls_ssl_set_bio(&ssl, &server_fd, 
2.         mbedtls_custom_send,//改寫後的mbedtls_net_send，為底層提供發送接口 
3.         mbedtls_custom_recv,//為底層提供接收接口 
4.         mbedtls_custom_recv_timeout) 

4.2 內存管理

自定義實現類型如下內存的申請和釋放接口:

1. void* calloc（unsigned int num，unsigned int size） 
2. void free(void * ptr) 

實現後將函數註冊給底層

1. mbedtls_platform_set_calloc_free(custom_calloc, custom_free) 

4.3 定時器

對DTLS定時器接口，並註冊到底層。

1. #if defined (__MBEDTLS_DTLS__) 
2.     
3.    //Set delays to watch 
4.    void platform_timing_set_delay(void *data, uint32_t int_ms, uint32_t fin_ms) 
5.    { 
6.     platform_timing_delay_context *ctx = (platform_timing_delay_context *) data; 
7.      
8.     ctx->int_ms = int_ms; 
9.     ctx->fin_ms = fin_ms; 
10.      
11.     if(fin_ms != 0) 
12.     { 
13.      ctx->snapshot = custom_get_systicks(); 
14.     }     
15.    }     
16.  
17.    //Get number of delays expired 
18.    int platform_timing_get_delay(void *data) 
19.    { 
20.     platform_timing_delay_context *ctx = (platform_timing_delay_context *) data; 
21.     unsigned long elapsed_ms; 
22.      
23.     if(ctx->fin_ms == 0) 
24.  { 
25.   return(-1); 
26.  } 
27.      
28.     elapsed_ms = custom_ticks_to_milli_secs(custom_get_systicks() - ctx->snapshot); //轉換成毫秒 
29.      
30.     if(elapsed_ms >= ctx->fin_ms) 
31.     { 
32.      return(2); 
33.     } 
34.      
35.     if(elapsed_ms >= ctx->int_ms) 
36.     { 
37.      return(1); 
38.     } 
39.      
40.     return 0; 
41.    } 
42.  
43.    #endif /* __MBEDTLS_DTLS__ */ 
44.     
45.    //註冊到底層 
46.    mbedtls_ssl_set_timer_cb( &ssl, &platform_timer, platform_timing_set_delay, platform_timing_get_delay ); 
47.     

4.4 網絡阻塞與非阻塞機制

mbedtls在電腦模擬測試時其網絡連接非常順暢，而且測試只是跑這一項功能，即使採用阻塞模式也不會有其它問題。實際嵌入式設備在聯網時，肯定還有其他任務需要執行。

如果設備支持作業系統，可以為mbedtls單獨分配一個線程或者任務，推薦使用阻塞機制實現接口，而且容易調試，尤其是https下載這種場景。但是特殊情況下不支持阻塞的，在改寫網絡接口時，需要特殊處理。

例如範例mbedtls_net_connect進行域名解析、連接伺服器，嵌入式設備的無線網絡在這個步驟，基本會返回異常表示阻塞等待中，要解決這個問題，需要將後續的握手流程拆分執行。原本聯網後執行mbedtls_ssl_handshake，在while裡面等待握手流程MBEDTLS_SSL_HANDSHAKE_OVER結束或者錯誤，改為每次收到讀消息的事件，執行一次或多次mbedtls_ssl_handshake_step。(這個並沒親自驗證)

mbedtls_ssl_set_bio註冊的讀寫接口支持設為非阻塞，mbedtls_ssl_write和mbedtls_ssl_read對應用層接口，在底層socket上報read_ready之後，判斷當前握手已經完成，再執行mbedtls_ssl_read。

4.5 證書與密鑰

測試可以使用mbedtls範例自帶的證書和公鑰、私鑰，但實際項目需要自己根據伺服器域名生成ca證書，以及雙方的公鑰、私鑰。在源碼programs\pkey下有秘鑰生成的代碼，作為客戶端，需要驗證伺服器提供的公鑰證書，因此本地還要CA證書，類似首次登錄12306提示要下載的證書，再加上客戶端自身的公鑰和私鑰，一共3個文件。gen_key.c生成keyfile.key私鑰，默認秘鑰長度是4096，雖然1024理論上有風險，但是運算更快;後面再使用openSSL 命令行生成公鑰。

1. OpenSSL> rsa -in private.key -pubout -out public.key 

openSSL下載地址 https://www.openssl.org/，安裝後提示使用收費，實際使用未見異常。秘鑰也可使用openSSL生成

1. OpenSSL>genrsa -out private.key 2048 

如果使用未知，使用help查看說明。至於CA證書，需要平臺側生成再提供給設備端。

4.6 加密套件與配置裁剪

確定合適的加密套件，未使用的算法就可以屏蔽;在電腦運行瞬間完成，在實際arm硬體可能需要較長時間，比如使用RSA在握手階段可能需要較長時間，可以選擇ECDSA或者減小秘鑰長度。

5、小節

目前的物聯網對數據安全不是很關注，使用自定義協議近似明文的方式交互，或者使用單一加密方式，未來智能家居、涉及財物計費的、特殊行業的設備節點，可能會逐漸使用加密通信，而mbedtls則是較好的選擇之一。即使不使用TLS，也可以選擇簡單的對稱加密，mbedtls也是一個加密算法庫，可根據需求提取合適的源碼集成。

本文轉載自微信公眾號「 嵌入式系統」，可以通過以下二維碼關注。轉載本文請聯繫 嵌入式系統公眾號。

【編輯推薦】

【責任編輯：

武曉燕

TEL：[phone]】

點讚 0