基于USB Key的安全增強密鑰生成方案

趙 波，李二輝 ，馬 駿 ，黃宇晴

1.武漢大學 計算機學院，武漢 430072

2.武漢大學 空天信息安全與可信計算教育部重點實驗室，武漢 430072

1 引言

近年來，嵌入式設備以其集成度高、體積小、功耗低等特點廣泛應用于工業(yè)控制、國防軍事、消費電子等多個領域。但是，由于嵌入式系統(tǒng)安全防護機制弱、易受物理攻擊等特點，其隱私數據的安全性正面臨嚴重威脅[1]。比如，國內電力部門采用特殊移動終端收集電能表數據等信息，經處理后上傳到云服務器端[2]。雖然給數據采集帶來了便捷性，但是該移動終端設備在設計時很少考慮針對隱私數據的保護機制，容易受到物理攻擊，造成用戶隱私信息泄漏的后果。又比如，智能終端常用來存儲用戶敏感信息，并廣泛應用于電子支付、身份認證等各個方面[3]。由于嵌入式系統(tǒng)的開放性，敏感數據存在被惡意程序竊取的風險；另外，一旦設備丟失，攻擊者就可能竊取敏感信息，并偽裝用戶身份進行非法操作。

針對嵌入式系統(tǒng)隱私數據泄漏的問題，目前已經出現了許多成熟的保護方案（比如加密保護、完整性檢測、訪問控制等），這些方案的安全級別主要取決于密鑰的安全強度[4]。如果密鑰泄漏，整個安全機制將會失效。因此針對密鑰的保護是保護嵌入式系統(tǒng)隱私數據的關鍵。

嵌入式系統(tǒng)的密鑰一般永久存儲在片外非易失性存儲器（NVM）中，智能終端的密鑰就是以這種方式進行存儲。攻擊者可以通過物理訪問NVM的方式直接竊取密鑰，也可以對NVM與芯片之間的信道進行偵聽，從而竊取密鑰[5]。為提高嵌入式系統(tǒng)密鑰的安全性，學者們設計了將密鑰存儲在片上NVM或者片上易失性存儲器（比如SRAM）的方法。但這些方法歸根結底都需要在嵌入式系統(tǒng)上存儲密鑰。只要攻擊者能夠物理訪問嵌入式系統(tǒng)，密鑰就存在泄漏的風險。特別的，當嵌入式系統(tǒng)不再通電時，存儲器的內容仍然被保留，攻擊者若對設備進行侵入式攻擊，就能竊取密鑰[6]。

針對嵌入式系統(tǒng)下密鑰存儲面臨的安全問題，本文提出了一種安全增強密鑰的生成方案。本文首先對安全增強密鑰（SEK）的特點進行了分析，并給出了利用USB Key生成SEK的詳細設計方案，最后對方案原型進行了實現。

2 背景知識

2.1 安全增強密鑰

本文提出的SEK在概念上是指天然地能夠有效抵抗針對嵌入式系統(tǒng)的物理攻擊的密鑰。它是一種僅在需要時生成，使用后即銷毀的密鑰，在其生成周期之外，攻擊者無法竊取SEK。在設計上，SEK由嵌入式系統(tǒng)和外設利用DHKE共同生成。僅僅擁有嵌入式系統(tǒng)或者僅僅擁有外設都無法生成SEK。攻擊者通過物理訪問嵌入式設備的方式無法得到生成SEK的有效信息，無法破壞生成SEK所需的相關數據，也無法通過偵聽信道的方式竊取密鑰。考慮到嵌入式設備的特殊性，本文方案以USB Key作為外設，利用USB Key的安全機制保護生成SEK的部分數據，進一步增強了攻擊者竊取SEK的難度。

2.2 DHKE

DHKE[7]是在公共信道上安全地協(xié)商密鑰的特定方法。它允許尚未認證的雙方在非安全信道上建立共同的密鑰。之后雙方可以利用此密鑰實現信息的安全傳輸，而不必擔心信息被竊取。DHKE的安全性基于有限域上計算大素數離散對數的困難性[8]。

2.3 USB Key

USB Key由智能卡技術演化而來，通常配有與智能卡相同標準的片上操作系統(tǒng)（COS）[9]。USB Key采用硬件與PIN碼相結合的方式進行身份認證，僅僅擁有USB Key或者僅僅擁有PIN碼都不能達到認證的目的。另外，基于USB Key自身固有的保護機制，外部不能直接訪問其存儲空間，而只能通過USB Key的程序實現[10]。

3 威脅模型與安全假設

通常情況下，嵌入式系統(tǒng)的隱私數據加密后存儲在NVM中。只要密鑰不泄漏，就能保證隱私數據的安全。密鑰一般存儲在片外存儲器或片上存儲器中。如果攻擊者能夠物理訪問嵌入式設備或者對嵌入式系統(tǒng)總線進行偵聽，就可能獲得密鑰從而竊取隱私數據。此外，如果攻擊者對密鑰進行破壞，即使合法用戶也無法還原隱私數據的真實涵義，此種情況下，相當于合法用戶丟失了隱私數據，造成的損失更為慘重。另外，由于無法保證嵌入式系統(tǒng)與外設之間信道的安全性，攻擊者可以發(fā)起信道攻擊，竊取雙方通信的交互數據。如果該數據含有生成密鑰的關鍵信息，就容易造成密鑰泄漏的后果。威脅模型如圖1所示。

圖1 威脅模型圖

本文方案利用USB Key通過DHKE為嵌入式系統(tǒng)提供密鑰，不考慮針對密鑰的邊信道攻擊。假設攻擊者可以物理訪問嵌入式設備，并能夠對嵌入式系統(tǒng)總線進行偵聽。此外，假設惡意程序可以在SEK生成周期內發(fā)起針對密鑰的攻擊，但無法破壞嵌入式系統(tǒng)內核訪問控制的保護機制。

4 方案設計

本章首先給出了本文方案的總體架構，對設計思路進行了詳細闡述，并對設計的各個模塊進行了介紹。之后給出了嵌入式系統(tǒng)（ES）與USB Key（UK）之間的認證方法，密鑰種子生成方案，以及SEK生成協(xié)議的詳細設計，并對方案中各部分的優(yōu)勢進行了分析。

4.1 架構

利用DHKE生成SEK的過程需要雙方協(xié)商進行。設計了密鑰協(xié)商模塊（KEM）來完成這種功能。KEM的功能主要是在ES端和UK端生成密鑰種子，之后利用密鑰種子進行DHKE協(xié)商運算，并利用協(xié)商出的結果生成SEK。總體架構如圖2所示。

圖2 總體架構圖

運行在UK上的KEM受UK固有安全機制的保護；ES上的KEM運行在內核空間，受操作系統(tǒng)內核訪問控制的嚴格保護[11]。接下來詳細描述各模塊的功能。

（1）密鑰交換模塊（Key Exchange Module，KEM）

KEM是本方案中的核心部分。雙方的KEM功能相似，代碼基本相同。該模塊包含以下3個模塊：

①密鑰交換運算模塊（Key Exchange Operation Module，KEOM）

KEOM用來執(zhí)行DHKE算法，該算法主要實現有限乘法群上的模乘操作。

②種子生成模塊（Seed Generation Module，SGM）

SGM是雙方密鑰種子的生成模塊，記ES端密鑰種子為s1，UK端密鑰種子為s2。該模塊由一個自創(chuàng)的算法實現。

③密鑰生成控制模塊（Key Generation Control Module，KGCM）

KGCM模塊對密鑰的生成過程進行控制。

（2）認證模塊（Authentication Module，AM）

AM是雙方進行認證的固有模塊，負責UK連入嵌入式設備時進行身份認證，主要是對PIN碼進行驗證。

4.2 認證模塊

UK與ES之間傳統(tǒng)的認證方式與一般的口令認證方式相同。即用戶在ES端輸入PIN碼后，經UK驗證通過才能獲得UK的使用權。在該認證過程中，如果攻擊者對信道進行偵聽，PIN碼就存在泄漏的風險。此外，惡意程序可以竊取認證過程中的會話信息數據并發(fā)起重放攻擊，破壞認證的安全性。因此傳統(tǒng)的認證協(xié)議安全性較弱，需要對其進行改進。

在本文方案中，UK與ES之間的安全認證是雙方互相確認合法身份的過程，也是保證正確生成SEK的前提。因此AM既需要驗證PIN碼的合法性，又需要驗證嵌入式設備的合法性。鑒于UK與ES之間信道的非安全性，傳統(tǒng)的認證協(xié)議無法達到安全認證的要求，本文方案在傳統(tǒng)認證協(xié)議的基礎上進行了改進。在認證之前，UK端須存有PIN碼和嵌入式設備唯一設備號DeviceID的度量值。在認證協(xié)議的會話信息中添加了隨機數n，抵抗重放攻擊；采用對DeviceID和PIN碼的哈希值進行驗證的方法，抵抗信道攻擊。改進后的認證協(xié)議的主要過程如圖3所示。

圖3 USB Key認證流程圖

步驟1 UK=＞ES：{n}，UK向ES發(fā)送隨機數n。

步驟2 ES=＞User：{request}，ES向User請求PIN碼。

步驟3 User=＞ES：{PIN}，User輸入PIN碼。

步驟4 ES：create(HP,HD)，ES利用sha1算法生成PIN碼的哈希值HP=hash( )PIN||n和Device ID的哈希值HD=hash( )

DeviceID。步驟5 ES=＞UK：{HP,HD}，ES發(fā)送HP,HD到UK。步驟6 UK：Verify(HP,HD)，UK讀取存儲區(qū)中PIN碼的值PIN′生成H′P=hash()PIN′||n ，并驗證與 HP是否相同；讀取DeviceID的度量值H′D，驗證與HD是否相同。之后返回驗證結果。

若驗證成功，ES與UK認證成功。若驗證失敗，終止操作并退出。

對比原有認證協(xié)議，在安全性方面，改進后的認證協(xié)議增加了對DeviceID的認證過程，可以確保嵌入式設備的合法性，能夠抵抗偽造平臺攻擊。此外，改進后的認證協(xié)議不是對PIN碼直接進行認證，而是采用對PIN碼哈希值進行驗證的方法，即使攻擊者偵聽到了UK與ES間傳輸的數據，也無法根據HP還原PIN碼，無法得到有價值的信息。另外，HP中加入了隨機數n，可以確保會話信息的新鮮性，惡意程序即使竊取了HP，仍然無法發(fā)起針對認證過程的重放攻擊。在性能方面，該認證協(xié)議只是引入了隨機數n和DeviceID，并增加了一些哈希運算操作，對認證效率影響很小，對用戶體驗幾乎沒有影響。因此該協(xié)議在提高安全性的同時，也具有很強的實用性。

4.3 密鑰種子的生成

SEK的生成需要密鑰種子s1,s2，且SEK的安全性主要取決于密鑰種子的安全性。因此針對密鑰種子的保護機制是實施安全策略的關鍵。

4.3.1 ES端KEM的加載機制

ES端的密鑰種子s1由SGM利用設備唯一硬件特征值UniqueValue生成，UniqueValue由KGCM利用嵌入式設備部分組件的序列號生成。為保證s1的隱私性，必須加強對密鑰生成算法的保護。將SGM的代碼存儲在UK端并受UK固有安全機制的保護，可以確保SGM的安全性，從而保證s1的隱私性。另外，鑒于ES的非安全性，KEM的代碼存儲在ES端容易遭受篡改攻擊。因此，本文方案將KEM的代碼存儲在UK端，僅在使用時加載到ES端，可以確保KEM的可靠性。

4.3.2 s1、s2的生成

s1、s2的生成流程如圖4。在ES端，首先從UK端加載KEM到ES內核態(tài)運行。KGCM調用系統(tǒng)API提取UniqueValue，并進行哈希運算。SGM利用UniqueValue的哈希值生成s1。在UK端，加載KEM后，KGCM首先查詢s2。若找到s2，直接讀取即可。否則，KGCM利用隨機數生成器提取nonce，SGM利用nonce生成s2，并將s2存儲在UK端。

圖4 密鑰種子生成流程圖

4.3.3 密鑰種子的安全性分析

s1、s2對物理攻擊具有抵抗性。由于SGM存儲在UK端，攻擊者對ES進行物理攻擊只能得到UniqueValue，無法得到密鑰生成算法，因此無法竊取s1，保證了s1的安全性；攻擊者對ES進行篡改攻擊，無法篡改UniqueValue，因此不能阻止s1的正確生成，保證了s1的可靠性。此外，本文方案的s1、s2具有容易更新的特點，對s1、s2的更新可以實現對SEK的更新，從而提高設計方案的靈活性。具體的，可以通過對SGM中密鑰種子生成算法的更新或者對nonce重新提取實現更新s1、s2的目的。

4.4 SEK生成協(xié)議

SEK是由ES與UK通過SEK生成協(xié)議生成，因此SEK生成協(xié)議的正確執(zhí)行對SEK的安全性至關重要。SEK生成協(xié)議由雙方的KEM執(zhí)行，因此需要確保雙方KEM的可靠性。在設計時，UK端KEM受UK固有安全機制的保護，ES端KEM采用從UK端加載的方法來確保其可靠性。此外，由于信道的非安全性，SEK生成協(xié)議的會話信息存在泄漏的風險，因此設計該協(xié)議時，需要保證即使攻擊者偵聽到了會話信息，也無法得到SEK。本文方案采用DHKE來創(chuàng)建SEK可以達到上述目的。

SEK生成協(xié)議執(zhí)行時，首先由ES和UK利用各自的密鑰種子s1、s2生成會話信息m1、m2。之后雙方交換會話信息，并利用各自的密鑰種子和收到的會話信息生成會話密鑰K1、K2。如果正確執(zhí)行DHKE，雙方生成的會話密鑰相同。該會話密鑰經過處理后就能得到所需的SEK。該生成協(xié)議具有安全性強、可靠性良好、易實現等特點。其安全性不依賴于會話信息的保密性，而主要依賴于密鑰種子的安全性，因此只要保證密鑰種子的安全性，即使攻擊者偵聽到了通信數據，也無法得到SEK。

SEK生成協(xié)議在雙方搭建KEM并生成密鑰種子之后開始執(zhí)行，參與實體為雙方的KEM。協(xié)議執(zhí)行的流程圖如圖5所示。

圖5 SEK生成協(xié)議流程圖

步驟1 UK_KEM=＞EK_KEM：{q,α}，UK_KEM向EK_KEM發(fā)送q，α。

步驟2 ES_KEM：generate(m1)；

UK_KEM：generate(m2)；

ES_KEM利用s1生成m1=αs1modq，UK_KEM利用s2生成m2=αs2modq。

步驟3 ES_KEM=＞UK_KEM：{m1}；UK_KEM=＞ES_KEM：{m2}。

雙方交換信息m1、m2。

步驟4 ES_KEM：generate(K1,m3)；

UK_KEM：generate(K2,m4)。

ES_KEM計算K1=(m 2)s1modq；m3=αK1modq。

UK_KEM計算K2=(m1)s2modq；m4=αK2modq。

如果雙方都正確執(zhí)行DHKE，會有

K1=(αs2)s1modq=(αs1)s2modq=K2。步驟5和步驟6將對此進行驗證。

步驟5 ES_KEM=＞UK_KEM：{m3}；

ES_KEM發(fā)送m3。

步驟6 UK_KEM：Verify(m3,m4)，UK_KEM驗證m3,m4是否相等。若驗證成功，返回結果并進行步驟7。否則驗證失敗，退出SEK的生成過程。

步驟7 ES_KEM：generate（SEK），destroy（related data）；

UK_KEM：destroy（related data）。

ES_KEM利用 K1生成SEK。SEK交付后，ES和UK銷毀相關數據，比如s1，K1，K2，m1，m2，m3，m4，SEK等數據，并清除內存中KEM。

在方案執(zhí)行過程中，鑒于信道的非安全性，K1、K2可能無法正確生成。因此該協(xié)議采用對m3、m4進行驗證的方法來確保K1、K2的正確生成。如果m1、m2在通信過程中被篡改，m3、m4將無法驗證成功。該驗證方案沒有額外增加驗證模塊（比如哈希運算模塊），而是通過DHKE代碼中固有的模乘運算模塊執(zhí)行，可以提高驗證效率，減少代碼量，增加代碼的重復利用率。

針對DHKE算法，假設攻擊者已知q和α，并且竊聽到信息m1、m2。攻擊者需要利用數據集{q,α,m1,m2}得到SEK，這個問題稱為迪菲-赫爾曼問題[12]。文獻[7]指出求解s1或s2是解決迪菲-赫爾曼問題的唯一方法。因此攻擊者必須計算m1或m2以α為底的離散對數。但是，對于攻擊者，利用m1計算s1或者利用m2計算s2，大概需要q1/2次操作[13]。只要選用合適的q，攻擊者無法通過針對DHKE的攻擊獲得密鑰[14]。

5 方案原型的實現

5.1 硬件平臺

對嵌入式設備和USB Key進行開發(fā)設計，實現了本文方案的基本功能。采用了hikey開發(fā)板作為本文方案的嵌入式設備，其處理器為HiSilicon Kirin 620，linux內核版本為4.1.2，配有2 GB LPDDR3 SDRAM內存，以及8 GB eMMC Flash，該開發(fā)板有兩個USB 2.0接口，符合本方案對USB端口的需求。對嵌入式設備的開發(fā)需要宿主機環(huán)境和交叉編譯環(huán)境。采用arm-linux-gcc作為編譯工具，并以minicom作為串口調試工具。采用深思洛克公司的精銳IV產品進行USB Key開發(fā)，該產品RAM容量為64 KB，芯片安全等級為EAL 5+，支持標準C語言編程，非常適合本文方案的原型開發(fā)。采用Keil C51 V8.09作為USB Key的開發(fā)工具。

5.2 軟件實現

在實際的開發(fā)過程中，本文方案所有的軟件實現都基于C語言來完成。具體實現過程中，主要增加了KEM相關代碼設計部分。對AM的改進設計直接在原有認證模塊上更改。

5.2.1 KEM的加載流程設計實現

將SGM、KGCM、KEOM的代碼存儲在UK端的存儲器中，UK端的COS可以直接加載并運行這些模塊。但是，在嵌入式系統(tǒng)端，僅在執(zhí)行生成SEK的任務時才加載相應的模塊并運行，因此需要在開發(fā)板上設計加載程序KEM_Loder，并且需要保證KEM_Loader的可靠性。KEM_Loader負責將KEM的代碼加載到內核態(tài)運行，從而為KEM提供訪問保護。在KEM_Loader運行前，為確保其代碼沒有被破壞，由OS Kernel對其進行度量，并交給UK進行驗證。如果KEM_Loader已經被破壞，由UK端加載備份的KEM_Loader到ES內核。在設計時，將KEM_Loader設計為linux Kernel的一部分，將度量函數KL_measure（）添加到內核中，并與linux Kernel一起植入hikey開發(fā)板的FLASH中。另外在USB Key的開發(fā)階段，將KEM_Loader的代碼和度量值HKL存儲在UK中。ES端KEM的加載流程如圖6所示。

圖6 嵌入式系統(tǒng)端KEM加載流程圖

5.2.2 密鑰種子的生成實現

嵌入式系統(tǒng)端密鑰種子的生成需要開發(fā)板的唯一硬件特征值UniqueValue。在實現過程中其數據結構定義如下：

struct{

char cpu_serial[CPU_SERIAL_LEN]； //用于保存CPU序列號

char board_serial[Board_SERIAL_LEN]； //用于保存開發(fā)板序列號

char flash_serial[FLASH_SERIAL_LEN]； //用 于 保 存FLASH序列號

}UniqueValue；

在ES端KGCM代碼中添加sha1哈希算法，該算法利用UniqueValue的值，實現生成160 bit的消息摘要HUV的功能。在SGM的代碼中構造函數Seed_Generation（），該函數實現密鑰種子生成的功能，以HUV為輸入，輸出2 048 bit的s1。在UK端KGCM代碼中添加隨機數生成算法，該算法利用隨機數生成器生成160 bit的隨機數。函數Seed_Generation（）能夠利用該隨機數生成2 048 bit的s2。雙方的函數Seed_Generation（）代碼相同，其功能是對輸入的160 bit的數據進行加擾和擴展，實現不唯一，靈活性很強，對該函數的更新可以作為對密鑰種子更新的一種方法。

5.2.3KGCM、KEOM的實現

本文的核心部分是KEM，鑒于UK資源有限，所設計的KEM的代碼量和計時，雙方的SGM和KEOM以減小代碼量，增加代碼要調用雙方系統(tǒng)各自的

因此雙方的KGCM功能相似，但實現不同。嵌入式系統(tǒng)端的KGCM主要由UniqueValue提取模塊、會話控制模塊、系統(tǒng)調用模塊、SEK生成模塊組成。UK端的KGCM主要由隨機數提取模塊、會話控制模塊、系統(tǒng)調用模塊組成。

利用開源的OpenSSL-0.9.8y來實現本文方案中所需的DHKE算法。在具體實現時，使用其中的Anonymous Diffie-Hellman的代碼來實現所需的功能。該版本的DHKE算法不包含基于簽名的認證過程，由于在DHKE執(zhí)行之前UK與ES已經完成了認證過程，因此該算法很適合本文方案的需求。DHKE算法中生成參數集{q,α}的操作會消耗大量計算資源，為減少UK和ES的開銷，在對UK進行開發(fā)設計時，即將參數集{q,α}寫入UK端。DHKE執(zhí)行時，UK只需讀取該參數集并發(fā)送給ES即可，不必額外執(zhí)行生成該參數集的操作。在DHKE算法中，q越大安全性越強，消耗的計算資源越多。為了兼顧DHKE算法的安全性和執(zhí)行效率，以2為有限循環(huán)群Gq?的生成元，采用2 048 bit的q。此時攻擊者如果對DHKE進行攻擊，大概需要q1/2≈220481/2=21024次操作。DHKE算法執(zhí)行后，生成的K1的長度與q的長度相同，也為2 048 bit。

由于不同的密碼算法對SEK長度有不同的要求（比如AES算法的密鑰長度可以是128 bit，192 bit，256 bit，三重DES算法的密鑰長度可能是112 bit或者168 bit），因此在ES端的KGCM中設計函數SEK_Create（）來滿足密鑰長度的不同需求。該函數以2 048 bit的K1為輸入，并輸出SEK。在具體的算法實現上采用sha1哈希算法對K1進行計算生成160 bit的key_material，并假設所需的SEK的長度為length。如果length≤160，只需取key_material的前l(fā)ength位作為SEK即可；如果length＞160，將key_material和 K1的前(length-160)位連接在一起生成SEK。

6 方案評估

本章將從方案原型的性能和安全性分析兩方面進行評估。

6.1 性能測試

主要測試SEK的生成過程對ES性能的影響。相對于從NVM上讀取密鑰K進行加密運算的方式，本方案SEK的生成過程可能會增加時間開銷。因此，性能測試采不同次結果如圖7所示

圖7 性能測試結果

以利用SEK進行加密運算的方案作為實驗組，并以直接讀取密鑰K進行加密運算的方案作為對照組。對照組AES加密過程的時間開銷主要由讀密鑰K的時間、讀明文數據時間、AES加密運算時間、寫密文數據時間構成；實驗組AES加密過程時間開銷主要由SEK生成時間、讀明文數據時間、AES加密運算時間、寫密文數據時間構成。從圖中可以看出，實驗組時間開銷均大于對照組，這是因為SEK的生成時間大于密鑰K的讀取時間。SEK生成時間不包含ES與UK認證的時間，約為4.12 ms，主要由DHKE算法進行的模乘操作運算時間和UK端與ES端傳輸數據時間構成。

SEK的生成增加了整個加密過程的時間消耗，但隨著數據長度增加，額外時間開銷占整個加密過程時間開銷的比例減小。當加密數據長度足夠大時，SEK的生成時間開銷幾乎可以忽略不計。因此本文的SEK生成方案增加的額外時間開銷在用戶可以接受范圍內，幾乎不影響用戶體驗。

6.2 安全性分析

本節(jié)首先分析了對密鑰存儲進行保護的現有各種方法的特點，然后分析了本文方案相對于現有方案的優(yōu)勢，并分析了本文方案對各種潛在攻擊的防護能力。

針對嵌入式環(huán)境下利用片外NVM存儲密鑰面臨的安全問題，國內外研究者已經展開了許多研究，設計了多種對密鑰存儲進行保護的方法。比如，利用片上NVM存儲密鑰的方法可以節(jié)省片上空間[15]，降低信道攻擊帶來的風險，但NVM在片上的位置容易被發(fā)現，且芯片斷電后密鑰仍存儲在片上NVM中，容易遭受侵入式攻擊[16]。利用片上易失性存儲器來存儲密鑰的方法靈活性較強，但會增加片上空間，并需要額外的電池為易失性存儲器供電，且該方案無法抵抗Cold Boot[17]等物理攻擊。物理不可克隆函數[18]（PUF）是進行密鑰生成的新興技術。當向PUF發(fā)送挑戰(zhàn)時，它會基于集成電路中的固有“指紋”產生響應，進而生成密鑰。但PUF會增加額外的片上面積開銷，且魯棒性較差。這使得PUF技術很難取代傳統(tǒng)的將密鑰存儲在NVM中的方法[19]。

相對于以上方法，本文方案采用技術成熟的UK作為外部設備通過DHKE的方式為ES提供安全增強密鑰，具有靈活性強、成本低、易實現等特點。該方案不會增加片上空間，可以抵抗現有的許多潛在攻擊。以下分析了本文方案對各種潛在攻擊的防護能力。

侵入式攻擊：侵入式攻擊是指攻擊者利用逆向工程或微探測的方法分析芯片電路結構，并能夠竊取片上NVM和片外NVM內容的攻擊方式。此種攻擊對嵌入式系統(tǒng)的安全性危害很大。但在本文架構中，SEK不在嵌入式設備上存儲，而是利用密鑰種子s1、s2生成，且生成算法存儲在UK端，攻擊者只能得到生成s1所需的設備唯一硬件特征值uniqueValue，而無法得到s1、s2，無法生成SEK。

信道攻擊：信道攻擊源于嵌入式系統(tǒng)的非安全性，假設攻擊者可以對ES與UK之間的信道進行偵聽，竊取會話信息，并能夠對會話信息進行破壞。攻擊者對信道進行偵聽可以獲得信息{q,α,m1,m2,m3}，但攻擊者利用該信息無法計算得到SEK。攻擊者也無法通過對會話信息的破壞得到SEK，而且通過本方案對K1和K2的驗證能夠察覺這種攻擊。

進程攻擊：進程攻擊是指惡意程序繞過進程隔離機制，非法地訪問進程內存空間，從而竊取敏感數據。本文方案的KEM代碼存儲在UK端，只有在SEK的生成周期內才允許由KEM_Loader加載到ES端，且SEK生成后立即從內存中釋放，可以保證KEM的可靠性，不給攻擊者留下針對KEM進行攻擊的機會。此外，KEM在內核空間運行，使得KEM受操作系統(tǒng)內核訪問控制更為嚴格的保護，能夠有效地抵御此種攻擊帶來的風險。

偽造平臺攻擊：此種攻擊是指攻擊者偽造嵌入式平臺，并誘使用戶接入。當用戶使用UK連入偽造的嵌入式設備后，竊取會話信息和密鑰。本文方案中ES與UK之間的認證具有平臺關聯性，UK可以通過對DeviceID的驗證發(fā)現此種攻擊，并拒絕服務。另外，即使攻擊者建立了偽造平臺與UK之間的連接，由于無法偽造生成s1所需的唯一硬件特征值UniqueValue，攻擊者無法生成對應的SEK。

篡改攻擊：篡改攻擊是指攻擊者對嵌入式設備數據進行篡改甚至破壞。在本文方案中，SEK的生成不需要提取ES端存儲器上的數據，僅需要嵌入式設備唯一硬件特征值UniqueValue。除非破壞嵌入式設備，否則攻擊者無法破壞UniqueValue，因此攻擊者無法阻止SEK的正確生成。另外，攻擊者可以對KEM_Loader的代碼進行破壞，但是UK能夠檢測到此種攻擊，并加載備份的KEM_Loader到ES端，從而確保KEM的正確加載執(zhí)行。

相對于傳統(tǒng)的密鑰存儲方法，本文的SEK不需要直接存儲，而是利用密鑰種子和DHKE生成。因此密鑰的安全性很大程度上取決于密鑰種子的安全性。攻擊者若要竊取s1，必須竊取USB Key端的密鑰種子生成算法，而該密鑰種子生成算法和s2都存儲在UK端的安全區(qū)域，即使合法用戶也無法直接讀取。此外，即使攻擊者獲得了UK及其相應PIN碼，如果無法物理接觸對應的嵌入式設備，攻擊者也無法生成SEK。因此，除非攻擊者獲得了PIN碼，USB Key，并能物理訪問對應的嵌入式平臺，否則無法生成SEK。此外，通過SEK的更新機制，可以提高密鑰生成的靈活性，并進一步降低密鑰泄漏的風險。

7 結束語

本文提出了一種為嵌入式系統(tǒng)動態(tài)地生成可重復使用的密鑰的方案。該方案利用USB Key固有的安全特性和DHKE來提高密鑰的安全性，能夠有效地解決嵌入式系統(tǒng)在密鑰存儲方面的安全問題。USB Key作為外部設備，不會增加嵌入式設備的片上面積開銷，不需要額外的電池供電。另外，對本文方案原型系統(tǒng)的測試結果表明，生成SEK的時間消耗在用戶可以接受的范圍內，具有較高的實用價值。

：

[1]Parameswaran S，Wolf T.Embedded systems security—an overview[J].Design Automation for Embedded Systems，2008，12（3）：173-183.

[2]Chen X，Liu H，Dai J.Security key designed for LAN and mobile terminal[C]//2013 Fourth World Congress on Software Engineering（WCSE），2013：121-124.

[3]趙波，費永康，向騻，等.嵌入式系統(tǒng)的安全啟動機制研究與實現[J].計算機工程與應用，2014（10）：72-77.

[4]Sadeghi A R，Naccache D.Towards hardware-intrinsic security：foundations and practice[M].New York：Springer-Verlag，2010.

[5]Xie Yufeng，Xue Xiaoyong，Yang Jianguo，et al.A logic resistive memory chip for embedded key storage with physical security[J].IEEE Transactions on Circuits and Systems II：Express Briefs，2016，63（4）：336-340.

[6]Zhao Shijun，Zhang Qianying，Hu Guangyao，et al.Providing root of trust for arm trustzone using on-chip sram[C]//Proceedings of the 4th International Workshop on Trustworthy Embedded Devices，2014：25-36.

[7]Diffie W，Hellman M.New directions in cryptography[J].IEEE Transactions on Information Theory，1976，22（6）：644-654.

[8]湯衛(wèi)東，李為民.利用Diffie-Hellman算法改進Kerberos協(xié)議[J].計算機工程與設計，2007，28（2）：343-345.

[9]Margalit Y，Margalit D，Kastershtien R.USB key apparatus for interacting with a USB host via a USB port：U S，Patent 6，763，399[P].2004-07-13.

[10]賈凡，謝蒂.USB Key保護進程的設計與實現[J].計算機工程與應用，2011，47（15）.

[11]Mavrogiannopoulos N，Trma? M，Preneel B.A linux kernel cryptographic framework：decoupling cryptographic keys from applications[C]//Proceedings of the 27th Annual ACM Symposium on Applied Computing，2012：1435-1442.

[12]Alias Y F B，Isa M A M，Hashim H.Sieving technique to solve the discrete log hard problem in Diffie-Hellman Key Exchange[C]//2015 IEEE Symposium on Computer Applications&Industrial Electronics（ISCAIE），2015：129-133.

[13]Pohlig S，Hellman M.An improved algorithm for computing logarithms overGF(p)and its cryptographic significance（Corresp.）[J].IEEE Transactions on Information Theory，1978，24（1）：106-110.

[14]Geary A C.Analysis of a man-in-the-middle attack on the Diffie-Hellman key exchange protocol[R].Naval Postgraduate School，Monterey，CA，2009.

[15]Li N，Mansouri S S，Dubrova E.Secure key storage using state machines[C]//2013 IEEE 43rd International Symposium on Multiple-Valued Logic（ISMVL），2013：290-295.[16]Skorobogatov S P.Semi-invasive attacks：a new approach to hardware security analysis[D].University ofCambridge，2005.

[17]Halderman J A，Schoen S D，Heninger N，et al.Lest we remember：cold-boot attacks on encryption keys[J].Communications of the ACM，2009，52（5）：91-98.

[18]Pappu R，Recht B，Taylor J，et al.Physical one-way functions[J].Science，2002，297（5589）：2026-2030.

[19]Helfmeier C，Boit C，Nedospasov D，et al.Physical vulnerabilities of physically unclonable functions[C]//Proceedings of the Conference on Design，Automation&Test in Europe，2014.