基于UEFI 的網絡加密文件傳輸技術的研究

樊 凱， 陳 浩， 白 丹

（1.中國兵器裝備集團自動化研究所有限公司， 四川綿陽 621000； 2.海軍裝備部， 四川綿陽 621900）

0 引言

BIOS（basic input and output system）是固化到計算機主板ROM 芯片上的程序[1]，負責硬件檢測和引導操作系統(tǒng)啟動。 傳統(tǒng)BIOS 固件基于匯編語言開發(fā)，維護困難，可擴展性差。 Intel 主導發(fā)布的統(tǒng)一可擴展固件接口UEFI （Unified Extensible Firmware Interface）逐漸取代了傳統(tǒng)BIOS[2]。UEFI 中引入了UEFI 驅動程序模型的概念，采用了驅動/協(xié)議的架構，具有很強的擴展性，從而使得UEFI 平臺下添加新的驅動和應用變得簡單[3]。

UEFI 在實際工程應用中存在以下兩個問題， 第一，在開發(fā)調試時，開發(fā)人員需要經常利用U 盤等工具將編譯好的固件文件拷貝到目標設備中進行調試，操作不便而且效率不高[4]。 第二、UEFI 固件發(fā)布后，由于軟件漏洞或新的需求，進行固件更新和維護在所難免，而在一些軍工行業(yè)的特定場合下， 目標設備通常禁止插入任何外帶存儲設備，這導致UEFI 固件的更新維護比較困難。UEFI Shell 提供了TFTP（文件傳輸協(xié)議）工具，但TFTP 協(xié)議是明文傳輸[5]，在通信過程中，信息容易被抓包竊取，不能保證傳輸過程的數(shù)據(jù)安全。

UEFI 框架中提供了對IPv4 網絡的支持， 本文基于TCP 協(xié)議與AES（Advanced Encryption Standard）對稱加密算法，實現(xiàn)了一種網絡加密傳輸工具，在局域網內通過網絡傳輸數(shù)據(jù)文件，支持調試與加密兩種工作模式，可以有效解決UEFI 應用中的痛點問題。

1 UEFI 網絡協(xié)議棧

1.1 協(xié)議棧簡介

UEFI 對IPv4 提供了支持，而且網絡接口協(xié)議也在不斷豐富和拓展，UEFI 網絡協(xié)議棧見圖1，包括鏈路層、網絡層、傳輸層和應用層的多種協(xié)議。 局域網中UEFI 網絡應用主要使用TCP、UDP 等傳輸層協(xié)議，應用程序與傳輸層、網絡層、鏈路層以及網卡驅動進行數(shù)據(jù)交互，實現(xiàn)與外界設備通信[6]。

圖1 UEFI 網絡協(xié)議棧

1.2 UEFI 下TCP 協(xié)議開發(fā)流程

UEFI 網絡協(xié)議棧傳輸層中常用的協(xié)議為TCP 協(xié)議和UDP 協(xié)議。 TCP 協(xié)議是面向連接的、可靠的數(shù)據(jù)傳輸網絡協(xié)議，可保證數(shù)據(jù)到達目的地。UDP 協(xié)議數(shù)據(jù)傳輸延遲小、傳輸效率高，但提供的是無連接的、面向事務的不可靠信息傳送服務。 本文采用了TCP 協(xié)議，UEFI 中TCP協(xié)議開發(fā)流程如下：

（1）創(chuàng)建Socket 對象：開發(fā)人員自定義一個Socket 結構體， 包含 EFI_TCP4_PROTOCOL、EFI_TCP4_CONFIG_DATA 和EFI_TCP4_RECEIVE_DATA 等協(xié)議對象的指針， 創(chuàng)建Socket 對象最重要的步驟就是實例化EFI_TCP4_PROTOCOL 對象，該協(xié)議提供了配置、連接、發(fā)送、接收和關閉接口，協(xié)議結構體定義如下：

實例化EFI_TCP4_PROTOCOL 對象并不能使用LocateProtocol、HandleProtocol 以及OpenPortocol 等常規(guī)協(xié)議接口從系統(tǒng)中獲得，而必須利用EFI_SERVICE_BINDING_PROTOCOL 創(chuàng)建和銷毀[7]。 協(xié)議結構體定義如下：

實例化EFI_TCP4_PROTOCOL 對象流程如下： 首先調用LocateProtocol 函數(shù)， 通過全局唯一標識符gEfiTCP4ServiceBindingProtocolGuid 在系統(tǒng)中找到EFI_SERVICE_BINDING_PROTOCOL 的實例對象，然后通過其成員函數(shù)CreateChild 創(chuàng)建子設備句柄， 并調用OpenProtocol 函數(shù)， 使用gEfiTCP4ProtocolGuid 在創(chuàng)建的子設備上安裝EFI_TCP4_PROTOCOL。 安裝成功后，就可以使用EFI_TCP4_PROTOCOL 對象的成員函數(shù)進行配置、連接、發(fā)送以及接收操作，使用完成后，再通過DestroyChild 函數(shù)來銷毀創(chuàng)建的EFI_TCP4_PROTOCOL 實例對象。

（2）配置本地端口和遠端服務器IP、端口。

（3）建立與遠端服務器的連接。

（4）發(fā)送、接收數(shù)據(jù)。

（5）Socket 使用完成后，關閉并銷毀Socket 對象。

2 加密算法

高級加密標準AES （Advanced Encryption Standard）為最常見的對稱加密算法， 對稱加密算法是指加密和解密用相同的密鑰。 AES 算法根據(jù)秘鑰長度不同可以進行多輪處理，每一輪加密包括字節(jié)替代、行移位、列混淆和輪密鑰加四個步驟， 解密流程正好相反。 AES 為分組密碼，包括五種工作模式：電碼本模式ECB、密碼分組鏈接模式CBC、計算器模式CTR、密碼反饋模式CFB、輸出反饋模式OFB[8]。ECB 模式結構簡單，可以分組獨立加密，是比較常用的模式，本文采用ECB 模式。

AES 加密算法應用成熟， 也有C 語言實現(xiàn)的開源代碼， 可以方便地移植到UEFI框架中，其使用流程見圖2。

圖2 AES 使用流程

設備1 中明文P 是原始明文數(shù)據(jù)，密鑰K 是用來加密明文的密碼，在對稱加密算法中， 加密與解密的密鑰相同。加密函數(shù)為E，經加密后的密文C=E（K，P）。 密文C 經網絡傳輸?shù)竭_設備2，解密函數(shù)D，經解密后的明文P=D（K，C）。

AES 秘鑰可以使用128 位、192 位或256 位， 密鑰越長，解密越難，但秘鑰并不是越長越好，需要綜合考慮處理器處理能力和實際應用環(huán)境，本文采用128 位秘鑰。在AES 標準規(guī)范中，分組長度只能采用128 位（16 個字節(jié)，不滿的部分需要填充數(shù)據(jù)）[9]，因此，在網絡加密文件傳輸工具設計時， 需要將數(shù)據(jù)包長度統(tǒng)一為16 字節(jié)的整倍數(shù)，不足的部分需要在信息段填充空白數(shù)據(jù)，在數(shù)據(jù)包解密后，需要根據(jù)數(shù)據(jù)長度，剔除無用信息。

3 網絡加密文件傳輸工具設計

網絡加密文件傳輸工具包含兩部分軟件， 第一部分是目標設備Target 上的UEFI Shell 應用軟件， 做TCP 客戶端，第二部分是主機Host 上的軟件，做TCP 服務器。目標設備做客戶端可以自主控制與指定IP、 端口號服務器的連接和數(shù)據(jù)傳輸流程， 避免做服務器時被網絡內未知客戶端惡意連接，傳輸病毒文件，保證目標設備的安全。網絡加密文件傳輸工具有調試（debug）和加密（release）兩種工作模式，固件發(fā)布前，使用調試模式，固件發(fā)布時，在客戶端代碼中限制，發(fā)布后必須使用加密模式。

3.1 通信協(xié)議設計

文件傳輸時，服務器與客戶端處于同一局域網內，為有效控制數(shù)據(jù)傳輸流程，需要設計傳輸通信協(xié)議，通信協(xié)議支持調試模式和加密模式。

通信協(xié)議格式見表1，一幀數(shù)據(jù)包由幀頭、指令碼、長度、信息段、CRC（指令碼、長度和信息段的循環(huán)冗余校驗碼）[10]和幀尾組成。 加密模式下，因為AES 加密算法要求分組數(shù)據(jù)必須是128 位， 所以將數(shù)據(jù)包分為標準幀和擴展幀兩種，標準幀長度16 字節(jié)，用于傳輸少量數(shù)據(jù)，比如文件長度和文件校驗碼，擴展幀長度4096 字節(jié)，用于傳輸文件內容數(shù)據(jù)。指令碼01，客戶端發(fā)起傳輸請求；指令碼02，服務器應答傳輸請求， 信息段內容為4 字節(jié)文件長度；指令碼03，服務器傳輸文件數(shù)據(jù)，信息段包含4字節(jié)幀序號和文件數(shù)據(jù)； 指令碼06， 服務器傳輸完成，信息段內容為2 字節(jié)文件校驗碼；指令碼04 和05，客戶端回復服務器接收狀態(tài)，信息段為填充的空白數(shù)據(jù)。

表1 通信協(xié)議

調試模式下無需遵循AES 規(guī)范，無需區(qū)分標準幀和擴展幀，長度指定為信息實際長度，信息段無需填充空白數(shù)據(jù)。

3.2 軟件工作流程

客戶端和服務器軟件調試模式下工作流程如下：

（1）啟動服務器，指定需要監(jiān)聽的IP、端口號和工作模式，等待客戶端連接。

（2）啟動客戶端，指定服務器IP、端口號和工作模式，建立與服務器的網絡連接。

（3）客戶端發(fā)起傳輸請求。

（4）服務器應答傳輸請求，同時傳輸文件長度。

（5）客戶端獲取文件長度，應答成功，準備接收文件數(shù)據(jù)。

（6）服務器分包發(fā)送文件數(shù)據(jù)。

（7）客戶端接收文件數(shù)據(jù)，應答成功。

（8）服務器傳輸完成，同時傳輸文件校驗碼。

（9）客戶端獲取文件校驗碼，比對接收的文件數(shù)據(jù)和文件校驗碼，成功后生成固件文件，傳輸過程完成。

在傳輸過程中，客戶端會校驗每一幀數(shù)據(jù)，校驗成功則應答成功，校驗失敗或接收超時，均應答錯誤，服務器接收到應答成功則傳輸下一包數(shù)據(jù)， 接收到應答錯誤則重新傳輸上一包數(shù)據(jù)。

加密模式下，客戶端每次啟動時會動態(tài)生成秘鑰，服務端需輸入相同的秘鑰，建立連接后，客戶端和服務器的每一包通信數(shù)據(jù)都要經過加密和解密過程， 工作流程見圖3。

圖3 傳輸工具工作流程

4 試驗驗證

本次試驗的目標設備為飛騰FT-2000/4 平臺， 預裝麒麟操作系統(tǒng)，主機為Intel（R） Xeon（E3）平臺，預裝Wondows7 旗艦版系統(tǒng)，目標設備第一次運行客戶端軟件FileTransfer.efi 時，需要先將其拷貝至硬盤，再將兩臺設備通過網線連接在同一局域網內。

在主機上準備好服務器軟件和固件文件， 先啟動服務器軟件，再啟動目標設備，通過BIOS 設置，進入UEFI Shell 中。 啟動客戶端軟件時，需要輸入服務器IP、端口號和工作模式三個參數(shù)。 其中， 第三個參數(shù)為 “debug”或“release”，調試模式下傳輸速率更快，方便快速調試與測試。固件正式發(fā)布時，將客戶端軟件代碼中的預定模式參數(shù)指定為release，固件發(fā)布后，輸入參數(shù)必須為release，在代碼內部會檢查輸入參數(shù)與預設參數(shù)一致性， 檢查通過后，生成16 字節(jié)動態(tài)秘鑰，將該秘鑰輸入到服務器軟件中，加密模式下，通過網絡發(fā)送接收的任何數(shù)據(jù)包都采用生成的動態(tài)秘鑰進行加密解密。 每次啟動客戶端軟件， 會重新生成秘鑰，充分保證數(shù)據(jù)的安全性。

在兩種工作模式下分別測試傳輸編譯后的固件文件，客戶端軟件調試模式傳輸試驗見圖4，加密模式傳輸試驗見圖5。

圖4 調試模式傳輸試驗

圖5 加密模式傳輸試驗

5 結束語

針對UEFI 調試維護時拷貝文件效率低下以及特定場合的設備禁止插入存儲設備帶來的升級維護困難問題，本文在TCP 協(xié)議和AES加密算法基礎上設計實現(xiàn)了網絡加密文件傳輸工具，在調試模式和加密模式下可以方便、安全地傳輸固件文件，適合應用在實際工程中。目前，該傳輸工具需要將動態(tài)秘鑰手動輸入服務器軟件，后續(xù)可進一步研究客戶端與服務器自協(xié)商生成動態(tài)秘鑰，提高使用便捷性。