當(dāng)一個(gè)嵌入式設(shè)備的TLS連接需要用到私鑰簽名而私鑰本身又不允許被應(yīng)用層代碼直接讀取時(shí)問(wèn)題就變得非常棘手。STM32H5的Secure Manager配合CycloneCRYPTO TLS棧恰好解決了這個(gè)“既要安全、又要可用”的矛盾。這篇文章圍繞實(shí)際項(xiàng)目中的外設(shè)所有權(quán)分配和Opaque Key處理把方案選型、配置流程、集成要點(diǎn)和踩坑實(shí)錄一次性講透。1. 項(xiàng)目場(chǎng)景與方案選型思路1.1 為什么在STM32H5上需要Secure ManagerSTM32H5系列采用的是Cortex-M33內(nèi)核配套TrustZone技術(shù)這讓芯片在硬件層面天然劃分出安全世界Secure World和非安全世界Non-Secure World。但很多開發(fā)者第一次接觸這個(gè)架構(gòu)時(shí)有個(gè)很直接的困惑我為什么要自己維護(hù)安全世界的固件安全啟動(dòng)、可信根、密鑰管理、加密算法庫(kù)這些東西都要自己寫、自己調(diào)試、自己保證沒有漏洞工作量非常大而且安全固件本身就是最容易被攻擊的部分。Secure Manager存在的意義就是把這些事全部接管。它是ST官方預(yù)置在芯片中的固定功能安全固件運(yùn)行在安全世界對(duì)外提供PSA Certified API。應(yīng)用開發(fā)者只需要在非安全世界調(diào)用它的接口就能完成密鑰管理、加密運(yùn)算、安全存儲(chǔ)、初始 attestation 等操作。換句話說(shuō)你不需要自己寫安全世界的代碼也不需要了解TrustZone底層的工作細(xì)節(jié)只要按照PSA API的規(guī)矩來(lái)調(diào)用就行。用ST官方的話說(shuō)Secure Manager為STM32H5提供了符合PSA Certified Level 3認(rèn)證的安全服務(wù)。Level 3意味著它不僅做了軟件隔離還包含了硬件防護(hù)能夠抵御物理攻擊比如側(cè)信道分析、故障注入、調(diào)試接口探測(cè)。對(duì)于物聯(lián)網(wǎng)設(shè)備、工業(yè)控制器、醫(yī)療設(shè)備這類對(duì)安全等級(jí)有硬性要求的產(chǎn)品這一步省下來(lái)的不只是開發(fā)時(shí)間更是安全審計(jì)時(shí)的底氣。1.2 為什么選CycloneCRYPTO而不是mbedTLSTLS協(xié)議棧的選擇我對(duì)比過(guò)mbedTLS和CycloneCRYPTO。mbedTLS在嵌入式領(lǐng)域知名度很高資料多社區(qū)活躍但它和Secure Manager的集成方式相對(duì)原始需要自己做很多膠水代碼。CycloneCRYPTO在這方面有個(gè)明顯的優(yōu)勢(shì)它本身就是為嵌入式環(huán)境設(shè)計(jì)的模塊化做得非常干凈TLS層和Crypto層分離底層可以靈活對(duì)接不同的硬件加速和安全服務(wù)。更重要的一點(diǎn)是CycloneCRYPTO對(duì)PSA Crypto API有較為成體系的適配思路。它允許你在TLS握手過(guò)程中把私鑰操作回調(diào)出去而不是像mbedTLS那樣默認(rèn)直接讀取內(nèi)存中的私鑰。這種架構(gòu)上的契合度讓我在集成Secure Manager時(shí)省了不少事。當(dāng)然mbedTLS也完全可以用如果你熟悉它的回調(diào)機(jī)制同樣能把私鑰操作轉(zhuǎn)發(fā)到Secure Manager。但從項(xiàng)目開發(fā)效率的角度看CycloneCRYPTO的分層設(shè)計(jì)讓我能更專注于業(yè)務(wù)邏輯而不是修補(bǔ)協(xié)議棧的邊界。1.3 整體架構(gòu)誰(shuí)在哪一側(cè)干什么活把整體架構(gòu)理清楚是項(xiàng)目啟動(dòng)前最重要的一步。在這個(gè)方案里系統(tǒng)被分為兩個(gè)世界安全世界這邊Secure Manager負(fù)責(zé)密鑰的生成、存儲(chǔ)、簽名、解密等所有涉及敏感材料的操作。非安全世界這邊跑的是你的應(yīng)用程序、網(wǎng)絡(luò)協(xié)議棧、CycloneCRYPTO TLS棧、還有RTOS。TLS握手過(guò)程中的私鑰簽名請(qǐng)求會(huì)經(jīng)由PSA API調(diào)度的方式進(jìn)入安全世界由Secure Manager完成簽名后返回結(jié)果。這中間最關(guān)鍵的點(diǎn)在于私鑰永遠(yuǎn)不需要離開安全世界。應(yīng)用代碼拿到的是一個(gè)Opaque Key Handle也就是不透明密鑰句柄通過(guò)它去引用安全世界中的密鑰對(duì)象。這個(gè)過(guò)程對(duì)TLS協(xié)議棧來(lái)說(shuō)是透明的協(xié)議棧只關(guān)心“給我一個(gè)簽名結(jié)果”完全不關(guān)心簽名是在哪里完成的。外設(shè)所有權(quán)則通過(guò)GTZCGlobal TrustZone Controller來(lái)分配。比如以太網(wǎng)外設(shè)、串口這類TLS需要訪問(wèn)的外設(shè)可以分配給非安全世界而Secure Manager自身需要的系統(tǒng)資源、存儲(chǔ)區(qū)域則保留在安全世界。具體的分配邏輯和配置方法下面會(huì)詳細(xì)展開。2. 外設(shè)所有權(quán)分配先劃清楚邊界才能談其他2.1 TrustZone世界劃分與Secure Manager的邊界在STM32H5上系統(tǒng)啟動(dòng)后默認(rèn)大部分資源歸安全世界所有。當(dāng)Secure Manager初始化完成后它會(huì)釋放一部分資源給非安全世界這個(gè)過(guò)程由芯片內(nèi)部的IDAUImplementation Defined Attribution Unit和SAUSecurity Attribution Unit共同決定。IDAU是芯片廠商定義的固定內(nèi)存映射規(guī)則哪些地址區(qū)域?qū)儆诎踩?、哪些屬于非安全在芯片出廠時(shí)就定死了代碼無(wú)法修改。SAU則是ARM內(nèi)核提供的一個(gè)可配置單元允許軟件在IDAU的基礎(chǔ)上進(jìn)一步細(xì)化安全屬性。對(duì)于開發(fā)者來(lái)說(shuō)理解這個(gè)機(jī)制的意義在于不是所有看起來(lái)要用的地址都能直接訪問(wèn)。如果你在非安全世界訪問(wèn)了一個(gè)被標(biāo)記為安全的地址會(huì)直接觸發(fā)HardFault或Security Fault。這類問(wèn)題在調(diào)試時(shí)特別讓人抓狂因?yàn)樗桓嬖V你具體原因只會(huì)看到程序突然死掉。Secure Manager會(huì)把自己的安全服務(wù)接口通過(guò)特定的內(nèi)存窗口暴露給非安全世界調(diào)用。這些窗口在出廠時(shí)已經(jīng)配置好你需要做的是確定自己的外設(shè)和內(nèi)存緩沖區(qū)分別放在哪一側(cè)然后嚴(yán)格按照這個(gè)劃分來(lái)寫代碼。2.2 用STM32CubeMX配置GTZC的實(shí)操步驟GTZC負(fù)責(zé)管理外設(shè)的安全屬性。在STM32CubeMX中你可以通過(guò)圖形化界面給每個(gè)外設(shè)分配安全或非安全屬性。操作路徑大致是在STM32CubeMX中選中STM32H5系列芯片后在Pinout視圖里找到GTZC然后在安全配置界面中你會(huì)看到所有外設(shè)的列表。將需要給非安全世界使用的外設(shè)勾選為Non-Secure將Secure Manager依賴的外設(shè)保留為Secure。以我這個(gè)項(xiàng)目為例需要分配的外設(shè)包括以太網(wǎng)MAC、PHY管理接口、相關(guān)DMA通道分配給非安全世界因?yàn)長(zhǎng)wIP協(xié)議棧跑在非安全側(cè)。USART用于日志輸出、配置指令下發(fā)分配給非安全世界。系統(tǒng)Tick定時(shí)器、SysTick中斷分配給非安全世界否則RTOS跑不起來(lái)。安全存儲(chǔ)相關(guān)的Flash區(qū)域保留在安全世界。這里有個(gè)容易忽略的細(xì)節(jié)當(dāng)你把一個(gè)外設(shè)設(shè)置為非安全屬性時(shí)它的中斷也要同步設(shè)置為Non-Secure否則中斷無(wú)法正常觸發(fā)。在CubeMX中這通常是在NVIC配置界面中完成但GTZC的安全配置不會(huì)自動(dòng)聯(lián)動(dòng)。我見過(guò)不少人在這一步踩坑外設(shè)已經(jīng)非安全了中斷還是安全的結(jié)果功能完全不正常。2.3 中斷、DMA和時(shí)鐘的權(quán)限細(xì)節(jié)外設(shè)所有權(quán)不只是“數(shù)據(jù)寄存器能不能訪問(wèn)”這么簡(jiǎn)單。中斷控制器、DMA通道、時(shí)鐘樹里每個(gè)外設(shè)的時(shí)鐘使能位都存在安全屬性問(wèn)題。在STM32H5上NVIC支持安全和非安全中斷。Secure Manager使用安全中斷來(lái)完成它的內(nèi)部調(diào)度用戶應(yīng)用使用非安全中斷。你在配置RTOS的SysTick、以太網(wǎng)接收中斷等都必須確保這些中斷被設(shè)置為Non-Secure狀態(tài)。如果你在非安全代碼里嘗試操作一個(gè)安全中斷的掛起或使能位會(huì)發(fā)生總線錯(cuò)誤。DMA方面STM32H5的DMA控制器支持按通道配置安全屬性。以太網(wǎng)收發(fā)使用DMA是常態(tài)你要么把用到的DMA通道都設(shè)置成非安全要么就用一個(gè)獨(dú)立的非安全DMA控制器。我建議直接按通道配置這樣靈活性更大調(diào)試時(shí)也方便逐個(gè)排查。時(shí)鐘配置是另一個(gè)容易漏掉的點(diǎn)。RCCReset and Clock Control模塊在GTZC中被視為一個(gè)外設(shè)它的安全屬性決定了非安全代碼能否修改時(shí)鐘樹。如果你在系統(tǒng)初始化階段把RCC分配給了安全世界而后面的外設(shè)驅(qū)動(dòng)在非安全世界試圖開啟某個(gè)外設(shè)時(shí)鐘會(huì)直接失敗。一般的做法是把RCC設(shè)置為非安全讓外設(shè)驅(qū)動(dòng)可以正常操作時(shí)鐘但Secure Manager自己的安全啟動(dòng)流程依賴的時(shí)鐘會(huì)在早期初始化完成后才會(huì)被釋放。這里有個(gè)實(shí)操技巧建議在CubeMX中把所有外設(shè)的安全屬性先整體規(guī)劃好不要一邊配置一邊改。因?yàn)橥庠O(shè)之間可能有依賴關(guān)系比如USART需要DMADMA又需要RCC如果只改了其中一個(gè)很容易引入隱蔽問(wèn)題。2.4 我踩過(guò)的外設(shè)所有權(quán)坑第一個(gè)坑是在以太網(wǎng)DMA上。當(dāng)時(shí)把ETH的MAC和PHY都設(shè)置成了非安全但DMA通道還留著安全屬性。結(jié)果就是PHY通信正常MAC寄存器也能訪問(wèn)但一旦啟用了DMA傳輸就觸發(fā)總線錯(cuò)誤。排查了很久才發(fā)現(xiàn)DMA通道的安全屬性沒有同步配置。這里提醒一句GTZC的安全配置是按外設(shè)顆粒度設(shè)置的但不代表外設(shè)內(nèi)部的所有子資源DMA通道、時(shí)鐘請(qǐng)求、中斷源都會(huì)自動(dòng)跟隨。第二個(gè)坑是RCC時(shí)鐘使能。最初我把RCC設(shè)置為安全后來(lái)發(fā)現(xiàn)從非安全世界調(diào)用HAL_RCC_ClockConfig時(shí)函數(shù)返回HAL_ERROR但沒有任何日志。一開始以為是對(duì)外設(shè)的時(shí)鐘配置寫錯(cuò)了排查了幾天才發(fā)現(xiàn)是GTZC的安全屬性擋住了非安全側(cè)的RCC操作。這個(gè)問(wèn)題的隱蔽點(diǎn)在于是它沒有HardFault就只是API返回錯(cuò)誤非常容易讓人的排查方向跑偏。第三個(gè)坑是調(diào)試接口。Secure Manager運(yùn)行后調(diào)試器默認(rèn)無(wú)法訪問(wèn)安全世界的資源。如果你想用J-Link或ST-LINK直接看安全世界的內(nèi)容需要在調(diào)試器的初始化腳本里使能調(diào)試授權(quán)同時(shí)設(shè)置好授權(quán)的安全等級(jí)。開發(fā)早期我把所有調(diào)試都放在非安全側(cè)結(jié)果每次想看Secure Manager內(nèi)部狀態(tài)都無(wú)從下手最后是通過(guò)Secure Manager自帶的tracer接口和日志輸出來(lái)解決的。3. Opaque Key處理讓私鑰“看得見卻拿不走”3.1 不透明密鑰機(jī)制的核心邏輯Opaque Key翻譯過(guò)來(lái)叫不透明密鑰。它是整個(gè)方案里最核心的一個(gè)概念應(yīng)用代碼通過(guò)一個(gè)句柄引用密鑰但密鑰本身的內(nèi)容永遠(yuǎn)不會(huì)暴露給使用者。你可以把它理解成一把被鎖在保險(xiǎn)柜里的鑰匙你拿到的是一個(gè)保險(xiǎn)柜的編號(hào)憑證用來(lái)讓別人幫你開鎖而不是真正擁有那把鑰匙。在Secure Manager的語(yǔ)境下這個(gè)機(jī)制由PSA Crypto API實(shí)現(xiàn)。你在安全世界中生成或?qū)朊荑€后Secure Manager會(huì)返回一個(gè)32位的密鑰標(biāo)識(shí)符key ID應(yīng)用代碼后續(xù)的操作都依賴這個(gè)ID。當(dāng)需要私鑰簽名時(shí)調(diào)用psa_sign_hash傳入密鑰ID、摘要和輸出緩沖區(qū)Secure Manager在安全世界完成簽名計(jì)算返回結(jié)果。為什么必須這樣設(shè)計(jì)因?yàn)門LS握手過(guò)程中客戶端使用私鑰進(jìn)行簽名這個(gè)簽名的最終結(jié)果是可公開的但私鑰本身一旦泄露安全體系就徹底崩潰。Opaque Key保證了即使非安全世界的代碼被完全攻破攻擊者也拿不到私鑰只能通過(guò)受限的API讓Secure Manager幫它簽名。3.2 PSA Crypto API的密鑰調(diào)用流程在實(shí)際的調(diào)用流程中你需要熟悉一組PSA API。下面這段以導(dǎo)入私鑰為例psa_key_attributes_t key_attrs PSA_KEY_ATTRIBUTES_INIT; psa_key_id_t key_id; psa_set_key_usage_flags(key_attrs, PSA_KEY_USAGE_SIGN_HASH); psa_set_key_algorithm(key_attrs, PSA_ALG_ECDSA(PSA_ALG_SHA_256)); psa_set_key_type(key_attrs, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1)); psa_set_key_bits(key_attrs, 256); psa_import_key(key_attrs, private_key_buffer, private_key_buffer_len, key_id);這段代碼做的事情是把一段私鑰字節(jié)流導(dǎo)入到Secure Manager中。導(dǎo)入完成后private_key_buffer這個(gè)緩沖區(qū)里存放的私鑰數(shù)據(jù)理論上可以擦除后續(xù)一切操作都通過(guò)key_id來(lái)引用。在TLS握手階段CycloneCRYPTO需要私鑰簽名時(shí)我們?cè)谶m配層實(shí)現(xiàn)一個(gè)回調(diào)把簽名請(qǐng)求分發(fā)到PSA APIpsa_sign_hash(key_id, PSA_ALG_ECDSA(PSA_ALG_SHA_256), hash, hash_len, signature, signature_capacity, signature_len);注意簽名算法必須和導(dǎo)入密鑰時(shí)設(shè)置的一致否則PSA API會(huì)返回錯(cuò)誤。在TLS 1.2中這個(gè)算法需要和證書簽名算法匹配TLS 1.3中因?yàn)楹灻惴▍f(xié)商的粒度更細(xì)這個(gè)約束更嚴(yán)格。3.3 密鑰導(dǎo)入與持久化的細(xì)節(jié)密鑰的導(dǎo)入方式有好幾種可以是純文本的私鑰導(dǎo)入也可以直接在安全世界內(nèi)部生成密鑰對(duì)內(nèi)導(dǎo)出公鑰。實(shí)際開發(fā)中我更推薦在Secure Manager內(nèi)部生成密鑰對(duì)因?yàn)檫@樣私鑰從誕生到使用全程沒有離開過(guò)安全世界。psa_generate_key(key_attrs, key_id);生成后通過(guò)psa_export_public_key導(dǎo)出公鑰再拿公鑰去制作CSR證書簽名請(qǐng)求然后交給CA簽發(fā)證書。這個(gè)過(guò)程既安全又符合邏輯。關(guān)于持久化PSA API提供了存儲(chǔ)屬性設(shè)置。通過(guò)psa_set_key_lifetime設(shè)置持久化生命周期密鑰就會(huì)保存到安全存儲(chǔ)中系統(tǒng)重啟后依然存在。這里要特別注意持久化密鑰的ID分配——建議用一個(gè)配置文件定義所有密鑰的ID避免重啟后代碼引用不到正確的密鑰。一個(gè)反復(fù)出現(xiàn)的坑是存儲(chǔ)在Flash中的密鑰備份問(wèn)題。如果設(shè)備需要固件升級(jí)且升級(jí)過(guò)程會(huì)擦除安全存儲(chǔ)區(qū)域必須提前考慮密鑰備份與恢復(fù)方案否則升級(jí)后設(shè)備證書還在但私鑰沒了會(huì)導(dǎo)致TLS握手徹底失敗。3.4 結(jié)合TLS握手的密鑰使用流程整個(gè)流程串起來(lái)看是這樣的系統(tǒng)啟動(dòng)Secure Manager初始化。非安全世界調(diào)用PSA API打開持久化的私鑰拿到key_id。網(wǎng)絡(luò)安全棧初始化LwIP或CycloneTCP開始監(jiān)聽TLS端口。客戶端發(fā)起TLS握手服務(wù)器發(fā)送證書并請(qǐng)求客戶端證書雙向認(rèn)證場(chǎng)景。CyCloneCRYPTO在握手過(guò)程中需要客戶端私鑰簽名調(diào)用適配層回調(diào)。適配層用key_id和握手摘要調(diào)用psa_sign_hash。簽名結(jié)果返回給TLS協(xié)議棧完成握手。對(duì)這個(gè)流程的直觀感受是TLS協(xié)議棧本身完全不知道Secure Manager的存在它只是調(diào)用了一個(gè)看起來(lái)像普通軟件實(shí)現(xiàn)的簽名函數(shù)。這層透明性是CycloneCRYPTO設(shè)計(jì)優(yōu)秀的地方。4. 集成CycloneCRYPTO TLS棧的關(guān)鍵環(huán)節(jié)4.1 CycloneCRYPTO分層架構(gòu)與適配點(diǎn)CycloneCRYPTO的架構(gòu)分為幾個(gè)層次底層是加密算法實(shí)現(xiàn)AES、ECC、RSA、SHA等中間是密碼學(xué)操作上下文cipher context、hash context上層是和TLS協(xié)議對(duì)接的TLS層最外層是一個(gè)平臺(tái)抽象層platform abstraction layer。平臺(tái)抽象層是你需要重點(diǎn)關(guān)注的地方。它定義了以下幾個(gè)關(guān)鍵接口隨機(jī)數(shù)生成用于TLS握手中的隨機(jī)數(shù)、臨時(shí)密鑰生成。時(shí)間獲取用于證書有效期驗(yàn)證。硬件加速回調(diào)用于把AES、SHA等運(yùn)算交給硬件加密引擎。內(nèi)存分配TLS握手過(guò)程中需要大量的動(dòng)態(tài)內(nèi)存分配CycloneCRYPTO支持兩個(gè)內(nèi)存區(qū)域數(shù)據(jù)面和堆面。其中隨機(jī)數(shù)和時(shí)間這兩個(gè)接口最容易出問(wèn)題。如果隨機(jī)數(shù)質(zhì)量不行TLS握手的隨機(jī)數(shù)就會(huì)弱化直接導(dǎo)致會(huì)話密鑰可預(yù)測(cè)。STM32H5內(nèi)置了TRNG真隨機(jī)數(shù)生成器可以直接用但要注意初始化順序TRNG外設(shè)在初始化完成后才能提供合格的隨機(jī)數(shù)提前調(diào)用會(huì)卡住或返回錯(cuò)誤。關(guān)于時(shí)間獲取很多嵌入式設(shè)備沒有RTC或者RTC沒校準(zhǔn)。如果證書驗(yàn)證使用的是絕對(duì)時(shí)間而系統(tǒng)時(shí)間是錯(cuò)的TLS握手會(huì)在證書有效期校驗(yàn)時(shí)報(bào)錯(cuò)。一個(gè)實(shí)用的做法是在產(chǎn)品出廠時(shí)寫入一個(gè)基準(zhǔn)時(shí)間后續(xù)通過(guò)NTP等方式同步。4.2 和Secure Manager的對(duì)接接口實(shí)現(xiàn)CycloneCRYPTO中私鑰操作是通過(guò)tlsSetEllipticCurvePrivateKey或tlsSetRsaPrivateKey等函數(shù)傳入。在標(biāo)準(zhǔn)使用中你需要傳入私鑰的內(nèi)容。但與Secure Manager對(duì)接時(shí)不能直接傳私鑰而是要傳一個(gè)回調(diào)函數(shù)。以ECDSA簽名為例在初始化TLS上下文時(shí)TlsContext tlsContext; tlsInit(tlsContext); tlsSetECDSASigningCallback(tlsContext, secureManagerEcdsaSignCallback);回調(diào)函數(shù)內(nèi)部實(shí)現(xiàn)PSA API簽名int32_t secureManagerEcdsaSignCallback(const TlsContext *context, const TlsKeyExchange *keyExchange, const uint8_t *digest, size_t digestSize, uint8_t *signature, size_t *signatureSize) { psa_key_id_t keyId (psa_key_id_t)keyExchange-privateKey; psa_algorithm_t alg PSA_ALG_ECDSA(PSA_ALG_SHA_256); if (psa_sign_hash(keyId, alg, digest, digestSize, signature, *signatureSize, signatureSize) ! PSA_SUCCESS) { return -1; } return 0; }這里有個(gè)很有意思的細(xì)節(jié)privateKey字段在標(biāo)準(zhǔn)實(shí)現(xiàn)中是一個(gè)指向私鑰結(jié)構(gòu)的指針但在對(duì)接Secure Manager時(shí)我們把這個(gè)字段的語(yǔ)義改成了存key_id。從數(shù)據(jù)類型的角度說(shuō)它仍然是一個(gè)整型變量所以不會(huì)產(chǎn)生編譯問(wèn)題。這種技巧在移植第三方TLS庫(kù)時(shí)非常常用相當(dāng)于在協(xié)議棧預(yù)留的接口上做了一層狀態(tài)注入。TLS客戶端驗(yàn)證服務(wù)器證書時(shí)也需要配置CA證書。這部分不涉及私鑰可以直接把CA證書鏈放在非安全世界因?yàn)镃A證書是公開信息。但如果你想做得更安全可以把CA證書也存入Secure Manager的安全存儲(chǔ)通過(guò)PSA API讀取。不過(guò)我建議不要這樣因?yàn)槊看挝帐侄家x取證書會(huì)拖慢性能而且CA證書泄露本身不構(gòu)成安全威脅。4.3 TLS會(huì)話建立流程與代碼實(shí)現(xiàn)下面是一個(gè)比較貼近實(shí)際項(xiàng)目的TLS服務(wù)器初始化流程// 初始化TLS上下文 TlsContext tlsCtx; TlsInit(tlsCtx); // 設(shè)置服務(wù)器證書 tlsSetCertificate(tlsCtx, serverCert); // 設(shè)置ECDSA簽名回調(diào)為Secure Manager適配層 tlsSetECDSASigningCallback(tlsCtx, secureManagerEcdsaSignCallback); // 設(shè)置密鑰交換參數(shù) TlsKeyExchange keyExchange; keyExchange.privateKey secureManagerKeyId; // 把keyId傳給適配層 tlsSetKeyExchange(tlsCtx, keyExchange); // 設(shè)置密碼套件列表 const TlsCipherSuite *cipherSuites[]; tlsSetCipherSuites(tlsCtx, cipherSuites, cipherSuiteCount); // 設(shè)置平臺(tái)抽象接口 TlsPlatformContext platformCtx; platformCtx.getRandom h5TrngGetRandom; platformCtx.getTime rtcGetTime; tlsSetPlatformContext(tlsCtx, platformCtx); // 開始握手 TlsPerformHandshake(tlsCtx, socket);這段代碼已經(jīng)在實(shí)際項(xiàng)目中跑通。整體來(lái)說(shuō)CycloneCRYPTO的API是清晰穩(wěn)定的不需要像mbedTLS那樣手動(dòng)管理握手狀態(tài)機(jī)。但需要注意TlsPerformHandshake是阻塞調(diào)用你必須確保它運(yùn)行在一個(gè)有足夠?？臻g的任務(wù)中如果用的是RTOS建議給它分配不小于8KB的棧。4.4 吞吐優(yōu)化與資源占用TLS握手的資源占用大致分布握手過(guò)程中需要為每個(gè)會(huì)話分配臨時(shí)緩沖區(qū)主要包括握手消息緩沖區(qū)、加密上下文等一個(gè)TLS 1.2握手的內(nèi)存峰值大約5-10KB。STM32H5的SRAM配置一般是640KB所以內(nèi)存不是瓶頸。性能方面TLS握手最耗時(shí)的操作是ECDHE密鑰交換和ECDSA簽名。在STM32H5上如果使用硬件加速的橢圓曲線運(yùn)算單個(gè)ECDSA簽名大概需要幾毫秒到幾十毫秒取決于時(shí)鐘頻率和優(yōu)化級(jí)別。如果完全靠軟件CycloneCRYPTO自帶的軟件實(shí)現(xiàn)也能跑但握手時(shí)間會(huì)明顯變長(zhǎng)用戶體驗(yàn)差很多。我把CycloneCRYPTO的底層哈希和對(duì)稱加密都切到了STM32H5的硬件加密引擎上實(shí)測(cè)TLS 1.2握手總耗時(shí)大約在200ms以內(nèi)100MHz主頻下后續(xù)數(shù)據(jù)傳輸?shù)耐掏铝恳材芘艿揭蕴W(wǎng)速率的90%以上。這個(gè)優(yōu)化就一句話在平臺(tái)抽象層的加密回調(diào)里調(diào)用HAL的硬件接口別讓它走軟件實(shí)現(xiàn)。5. 常見握手失敗與安全加固排查實(shí)錄5.1 TLS憑據(jù)創(chuàng)建失敗內(nèi)部錯(cuò)誤狀態(tài)10013的排查思路現(xiàn)實(shí)中遇到“創(chuàng)建TLS客戶端憑據(jù)時(shí)發(fā)生嚴(yán)重錯(cuò)誤內(nèi)部錯(cuò)誤狀態(tài)為10013”這種問(wèn)題在嵌入式TLS服務(wù)器端也會(huì)以類似的形式出現(xiàn)常見的是客戶端返回TLS alert服務(wù)端日志顯示handshake failure。10013這個(gè)錯(cuò)誤在Windows的SSPI體系里大致意思是安全包無(wú)法找到或憑據(jù)創(chuàng)建失敗。如果是嵌入式設(shè)備作為TLS客戶端去連接遠(yuǎn)程服務(wù)器出現(xiàn)類似報(bào)錯(cuò)通常可以從幾個(gè)方向排查第一證書鏈不完整或證書格式不兼容。STM32H5上存放證書時(shí)如果格式是DER而服務(wù)器要求的是PEM或者證書鏈中間證書缺失都可能導(dǎo)致客戶端無(wú)法構(gòu)造可接受的憑據(jù)。第二私鑰類型與算法套件不匹配。很多設(shè)備商喜歡用RSA證書但你的TLS棧默認(rèn)密碼套件列表可能壓根不含RSA套件。比如CycloneCRYPTO的默認(rèn)配置如果只啟用了ECDSA套件你拿著RSA私鑰的證書去握手報(bào)錯(cuò)信息就是你看到的這個(gè)樣子。第三時(shí)間不同步。證書有效期的驗(yàn)證依賴系統(tǒng)時(shí)間。設(shè)備出廠時(shí)如果時(shí)間沒校準(zhǔn)證書會(huì)顯示已過(guò)期或未生效。一個(gè)建議是排查這類TLS握手失敗時(shí)不要只看錯(cuò)誤碼本身先去打開TLS調(diào)試日志。CycloneCRYPTO提供了TLS_TRACE_LEVEL宏開啟后能打印詳細(xì)的握手過(guò)程比對(duì)著報(bào)錯(cuò)碼猜要高效得多。5.2 CVE-2011-1473重協(xié)商攻擊的防護(hù)CVE-2011-1473描述的是TLS客戶端發(fā)起的重協(xié)商攻擊。攻擊者在己方控制的TLS連接中在未完成握手時(shí)通過(guò)重協(xié)商請(qǐng)求注入數(shù)據(jù)可能導(dǎo)致數(shù)據(jù)保密性問(wèn)題。實(shí)際上現(xiàn)在的安全掃描器在掃描嵌入式設(shè)備時(shí)如果發(fā)現(xiàn)支持TLS重協(xié)商且未啟用RFC 5746安全重協(xié)商擴(kuò)展就會(huì)報(bào)這個(gè)漏洞。在STM32H5設(shè)備上這個(gè)問(wèn)題的處理方式有兩層。第一層是協(xié)議棧層面。CycloneCRYPTO在TLS 1.2實(shí)現(xiàn)中支持安全重協(xié)商。你需要在編譯配置中啟用TLS_RENEGOTIATION_SUPPORT并且確認(rèn)啟用了TLS_SECURE_RENEGOTIATION_SUPPORT。如果掃描器還是報(bào)漏洞說(shuō)明可能啟用了客戶端發(fā)起的重協(xié)商而且沒有回退機(jī)制。最省事的防護(hù)措施是在服務(wù)器端禁止在握手完成后接受客戶端發(fā)起的重協(xié)商請(qǐng)求或者直接不啟用重協(xié)商。第二層是安全策略層面。如果你的業(yè)務(wù)場(chǎng)景完全不需要TLS重協(xié)商干脆把重協(xié)商功能編譯掉。攻擊面越小越安全這是嵌入式安全的基本原則。實(shí)際操作起來(lái)我在CycloneCRYPTO的配置文件中修改了下面兩個(gè)宏#define TLS_RENEGOTIATION_SUPPORT DISABLED #define TLS_SECURE_RENEGOTIATION_SUPPORT ENABLED其實(shí)第二個(gè)宏在第一個(gè)被禁用的情況下沒有實(shí)際意義但保留它表示你確認(rèn)理解了這個(gè)安全機(jī)制的作用方便后續(xù)代碼審查的人理解設(shè)計(jì)意圖。5.3 CVE-2016-2183 3DES弱算法問(wèn)題CVE-2016-2183是SWEET32攻擊相關(guān)的漏洞本質(zhì)是3DES和DES等64位分組密碼算法在長(zhǎng)期連接場(chǎng)景下會(huì)泄露明文信息。安全掃描器檢測(cè)到設(shè)備支持TLS_RSA_WITH_3DES_EDE_CBC_SHA之類的密碼套件時(shí)就會(huì)報(bào)這個(gè)漏洞。嵌入式設(shè)備默認(rèn)會(huì)編譯很多密碼套件為了兼容老客戶端。但在實(shí)際部署中我強(qiáng)烈建議只保留TLS 1.2及以上版本的強(qiáng)套件。以CycloneCRYPTO為例它的密碼套件列表在tls_cipher_suites.c中定義你需要把3DES相關(guān)的套件從列表中移除。我自己在項(xiàng)目中的密碼套件選擇原則是優(yōu)先ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。其次ECDHE_RSA_WITH_AES_128_GCM_SHA256。如果不考慮兼容性只保留這兩條就夠了。要注意的是移除3DES套件后如果你的客戶端沒有更新可能連不上設(shè)備。但這是值得的SWEET32的影響在低速嵌入式設(shè)備上更明顯設(shè)備長(zhǎng)期運(yùn)行大量連接時(shí)攻擊者可以收集到足夠的密文來(lái)分析。5.4 證書驗(yàn)證和TLS alert 40的排查建議如果客戶端報(bào)出“從遠(yuǎn)程終點(diǎn)接收到嚴(yán)重警告TLS協(xié)議所定義的嚴(yán)重警告代碼為40”也就是handshake_failure這個(gè)錯(cuò)誤是最通用的TLS握手失敗提示。它出現(xiàn)的場(chǎng)景很多但歸納起來(lái)常見原因也就幾類服務(wù)器端沒有可用的密碼套件與客戶端匹配。客戶端證書驗(yàn)證失敗。簽名驗(yàn)證失敗。TLS版本不匹配。針對(duì)嵌入式TLS服務(wù)器我給一個(gè)比較高效的排查順序先看客戶端支持的TLS版本和服務(wù)端是否一致再用抓包工具看看ClientHello里帶了哪些密碼套件最后看服務(wù)端有沒有輸出日志說(shuō)明具體是哪個(gè)環(huán)節(jié)失敗。在使用Secure Manager的場(chǎng)景里有個(gè)特殊的可能ECDSA簽名回調(diào)返回錯(cuò)誤。因?yàn)镾ecure Manager要求簽名算法和密鑰屬性必須匹配如果握手時(shí)協(xié)商出的簽名算法與key_id對(duì)應(yīng)的密鑰屬性不一致PSA API會(huì)拒絕簽名最終表現(xiàn)就是TLS alert 40。排查時(shí)看到日志里握手失敗但前面什么都正常就要想到去檢查密鑰屬性配置。6. 寫在最后幾個(gè)值得堅(jiān)持的實(shí)踐習(xí)慣項(xiàng)目做完后回頭總結(jié)有幾個(gè)經(jīng)驗(yàn)想分享給后來(lái)者。第一安全設(shè)計(jì)不能后期補(bǔ)丁。外設(shè)所有權(quán)分配和密鑰管理方案一定要在項(xiàng)目一啟動(dòng)就規(guī)劃好。如果先調(diào)通了非安全世界的TLS再回過(guò)頭去加Secure Manager你會(huì)發(fā)現(xiàn)外設(shè)屬性、中斷映射、密鑰導(dǎo)入等一堆東西都要返工工作量翻倍。第二日志和調(diào)試能力是安全開發(fā)的生命線。Secure Manager本身是黑盒出了問(wèn)題很難直接觀察所以要盡早接入它提供的調(diào)試通道。在項(xiàng)目的開發(fā)板上別把Secure Manager的調(diào)試功能關(guān)掉否則遇到問(wèn)題只能盲猜。第三密鑰ID管理要像數(shù)據(jù)庫(kù)主鍵一樣嚴(yán)肅。建立一個(gè)key_id的映射表每個(gè)密鑰都有明確用途和生命周期。不要為了省事在代碼里硬編碼隨機(jī)key_id調(diào)試時(shí)你會(huì)后悔。第四安全掃描器的報(bào)告要認(rèn)真過(guò)一遍。CVE-2011-1473和CVE-2016-2183是最常見的嵌入式設(shè)備安全掃描項(xiàng)如果你把這些都處理干凈了整個(gè)方案的安全性已經(jīng)超過(guò)了大多數(shù)同類產(chǎn)品。第五也是我在反復(fù)折騰中體會(huì)最深的一點(diǎn)Secure Manager Opaque Key這套組合真正的價(jià)值不只是在技術(shù)層面隔離了密鑰而是在產(chǎn)品迭代過(guò)程中你不需要因?yàn)榘踩珯C(jī)制去修改業(yè)務(wù)代碼所有的安全邏輯都收斂在邊界很清晰的PSA API背后。這種架構(gòu)帶來(lái)的安全感是開發(fā)過(guò)程中最值錢的隱形財(cái)富。