TWI580285B

TWI580285B - Ｈ（ｅ）ＮＢ完整性驗證及認證方法及裝置

Info

Publication number: TWI580285B
Application number: TW104122828A
Authority: TW
Inventors: 蘇西耶帕塔爾; 車尹赫; 安德魯斯史密特; 安德魯斯萊赫; 尤根德拉夏; 多洛莉絲和特; 大衛格瑞那; 勞倫斯卡斯; 麥克梅爾斯汀; 路易斯顧吉恩
Original assignee: 內數位專利控股公司
Priority date: 2009-03-05
Filing date: 2010-03-05
Publication date: 2017-04-21
Also published as: WO2010102222A2; TWI531254B; KR101649465B1; JP2012520024A; KR20110126160A; KR101691603B1; KR20170001737A; TW201616881A; KR20160100410A; JP2014096830A; US9253643B2; BRPI1006524A2; TW201130331A; EP2404460A2; CN104918252A; JP2017153101A; KR101607363B1; JP5785277B2; US20110041003A1; KR20120036350A

Description

H(e)NB完整性驗證及認證方法及裝置

本申請涉及通信。

家庭演進型節點B(H(e)NB)，也被稱為毫微微胞元(femtocell)基地台，是一種小的、可攜式的3G網路存取點，它們通常被佈置在房屋上或者稱為主機方(HP)的相關者的室內。H(e)NB成為了在小的、特定的地理區域內提供移動通信和服務的折中方案。H(e)NB可用於在目前的盲區(由於不好的無線電條件)例如室內或者工廠環境內提供移動服務。H(e)NB也可以成為私人家庭以及家庭辦公(SOHO)區域的選擇，這是因為H(e)NB可用作寬頻網際網路和移動網路的統一的存取點。

本申請會提出特別的安全要求。例如，這些裝置i)不再是像移動手持設備傳統地被認為的那樣，被當成是用於儲存和處理敏感資料的封閉的、不變的環境了；以及ii)這些特殊的裝置典型地不是由移動網路處理器(MNO)直接進行實體控制的，MNO作為H(e)NB的主要相關器件處理H(e)NB以為移動通信終端使用者提供服務；以及iii)這些設備通常通過不安全的鏈路及斷斷續續的而不是連續的方式而連接到核心網路。

現有的或標準的移動通信網路技術可能不為網路提供完全認為它所處理的H(e)NB是值得信任的方法，即使H(e)NB通過了傳統的鑑定(authentication)步驟。所需要的就是一種方法來幫助MNO鑑定及確認這種可信性、即設備的完整性，以及管理和提供這樣的設備。

公開了一種使用自動確認和半自動確認來為家庭演進型節點B(H(e)NB)提供完整性確認的裝置和方法。

ACS‧‧‧自動配置伺服器

C_DB‧‧‧配置策略資料庫

CPE‧‧‧使用者端設備

Cpman‧‧‧配置策略管理器

DMS‧‧‧設備管理系統

eNB‧‧‧演進型節點B

E-UTRAN‧‧‧演進型全球陸地無線電存取網路

FBC‧‧‧後備代碼

FTP‧‧‧檔傳輸協議

HMS‧‧‧家庭節點B管理系統

H(e)MS‧‧‧H(e)NB管理系統

H(e)NB‧‧‧家庭演進型節點B

HTTP/HTTPS‧‧‧文字傳輸協定安全

IKE‧‧‧網際網路密鑰交換

LAN‧‧‧局域網

MME‧‧‧移動性管理實體

OAM‧‧‧操作、行政和管理伺服器

OTA‧‧‧無線電

PCR‧‧‧平台配置暫存器

PVE‧‧‧平台確認實體

PVM‧‧‧平台確認和管理

RIM‧‧‧參考完整性度量

RIMman‧‧‧參考完整性度量管理器

RM‧‧‧參考清單

RoT‧‧‧信任根

SeGW‧‧‧安全閘道

SSL‧‧‧安全插口層

TCG‧‧‧可信的計算組

TCP‧‧‧傳輸控制協定

TPM‧‧‧可信的平臺模組

T_PVM‧‧‧PVM權杖

TrE‧‧‧可信的環境

TRV‧‧‧可信的參考值

UE‧‧‧使用者實體

URL‧‧‧統一資源定位器

V_DB‧‧‧確認資料庫

WAN‧‧‧廣域網

WTRU‧‧‧無線發射/接收單元

從以下描述中可以更詳細地理解本發明，下面的描述是以實例的形式給出的，並且可以結合附圖被理解，其中：第1圖示出了模組、功能性和元件的示例性結構；第2圖示出了組件和功能性的示例性結構；第3圖示出了用於軟體下載提供的示例性TR069架構；第4圖示出了基本的完整性測量和報告的實例；第5圖示出了完整性報告和參考材料的實例；第6圖示出了將確認報告與參考清單進行比較的實例；第7圖示出了參考清單中的元件資訊的實例；第8圖示出了認證管理架構的實例；第9圖示出了重新配置家庭演進型節點B(H(e)NB)(H(e)MS)的實例；第10圖示出了自動確認(AuV)補救的實例；第11圖示出了檔包格式的實例；第12圖示出了半自動確認(SAV)的網路架構的實例；第13A圖和第13B圖示出了SAV過程的示例性流程圖；第14圖示出了示例性SAV補救流程圖；第15圖示出了示例性完整性校驗結果；第16圖示出了示例性失敗的功能性的列表；第17A圖是表示示例性實體集合和它們之間的關係以及平台確認和管理(PVM)的介面的方塊圖；第17B圖是表示另一示例性實體集合和它們之間的關係以及PVM介面的方塊圖；第18A圖、第18B圖和第18C圖是使用平台確認實體的示例性確認方法的信號圖；第19圖示出了長期演進(LTE)無線通信系統/存取網路；以及第20是LTE無線通信系統的示例性方塊圖。

當在下文中提及時，術語“無線發射/接收單元(WTRU)”包括但不局限於使用者設備(UE)、移動站、固定或移動使用者單元、傳呼機、胞元電話、個人數位助理(PDA)、電腦、或能在無線環境中運行的任何其他類型的設備。當在下文中提及時，術語“基地台”包括但不局限於節點-B、站點控制器、存取點(AP)、閘道、使用者預定設備(CPE)、或能在無線環境中運行的任何其他類型的周邊設備。當在下文中提及時，術語“HMS”包括但不局限於家庭節點B管理系統(HMS)、家庭增強型節點B管理系統(HeMS)(這兩者可總稱為H(e)MS)、設備管理系統(DMS)、配置伺服器(CS)、自動配置伺服器 (ACS)、或者其他任何類型的管理“基地台”的配置或功能性的系統。術語“WTRU”和術語“基地台”互不衝突。例如，WTRU可以是增強型家庭節點B(H(e)NB)。當在下文中提及時，術語“資訊理論安全”包括但不局限於完全安全、無條件安全以及近似資訊理論安全。當在下文中提及時，術語“信任”、“可信的”以及“值得信任的”以及其他變化的說法表示一種可計量的以及可觀察的方法，該方法用於評定一個部件是否會以特定方法工作。

本文描述的是一種使用自動確認(AuV)和半自動確認(SAV)來為家庭演進型節點B(H(e)NB)提供完整性驗證和確認的裝置和方法。描述是先詳細描述AuV和SAV的共同部分，然後再分別描述AuV和SAV的實施詳情。

本文描述了在確認方法中確定可信的參考值(TRV)的方法。設備完整性校驗是確認方法的一種常用過程。對於設備完整性校驗，需要一組TRV以使由元件組成的測量可用於它們的完整性校驗。這種元件的完整性校驗應在元件裝載之前進行是可取的。這樣的TRV在使用之前需要進行鑑定及自我確保完整性也是可取的。

為了進行完整性校驗及提供和產生TRV，可以使用不同的完整性校驗方法。例如，可以考慮根據編碼產生TRV的方法、包括數位簽名方法、基於廢料(hash)的訊息鑑定碼或者基於加密的訊息鑑定碼。

這裏描述的是數位簽名方法。數位簽名可以使用公鑰加密技術。H(e)NB可以對模組的廢料(或者通常說的校驗字)進行數位簽名，通過使用它的私有密鑰對校驗字進行加密。加密的校驗字然後可以被發送到平台確認實體(PVE)，在那裏它會被用H(e)NB的公用密鑰進行解密並與TRV進行比較。對於本地完整性校驗，參考完整性校驗可以由製造商簽名並在H(e)NB內進行本地驗證。作為沒有限制性的實例，表1列出了一些數位簽名方法。

這裏描述的是廢料演算法和基於廢料的訊息鑑定碼。廢料是一種單向或者近似單向的函數，它產生其輸入的唯一的(或近似唯一的)並且不可逆的(或近似不可逆的)總結。許多情況中，數位簽名僅僅就是加密的廢料。而數位簽名方法可以使用公共/私有密鑰對，訊息鑑定碼(MAC)可以使用共用的秘密密鑰。校驗字可以在帶有嵌入的秘密密鑰(連接的模組和密鑰)的模組上產生。作為沒有限制性的示例，表2列出了一些廢料演算法及基於廢料的訊息鑑定碼的方法。

這裏描述的是基於加密的訊息鑑定碼。校驗字可以由廢料演算法產生然後使用秘密密鑰進行加密。作為沒有限制性的實例，表3列出了一些基於加密的訊息鑑定碼方法。

完整性度量是由在軟體元件上執行完整性方法產生的摘要(例如，加密的廢料值)。這裏認為元件是完整性校完整性度量是由在軟體元件上執行完整性方法產生的摘要(例如，加密的廢料值)。這裏認為元件是完整性校驗的最小的可能單元。單獨的二進位可執行或預可執行檔是元件的實例。另外，模組在這裏被認為是指套裝軟體的製造商認證、發佈的最小單元。對於本描述的剩餘部分，總體上考慮及如第1圖所示，1)元件也可能由一個或多個模組組成，以及2)任何一個模組只在一個元件中出現一次(也就是說一個模組不能出現在兩個元件中)。為支援用AuV和SAV進行設備完整性校驗和確認，可能需要提供軟體模組及其關聯的屬性的列表，這些關聯的屬性例如與模組相關的參考完整性度量(RIM)、嚴重性以及其他資訊。參考完整性度量(RIM)作為各個模組的完整性的參考值。在使用AuV時，所述列表可以由製造商產生並安全地儲存在設備中，當使用SAV時，所述列表可由製造商產生並提供給平台確認實體(PVE)(所有模組)並且也提供給H(e)NB(在多步驟系統中作為步驟1和步驟2模組啟動實施)。由於軟體模組怎樣進行組織、架構或儲存，以及設備可能存在什麼種類的模組可能依賴於H(e)NB的實施，因此可以使用公共的規範語言來說明模組及其屬性。

例如，基於可擴展標記語言(XML)和抽象語法定義一(ASN.1)的方法可被用作實施公共的規範語言。設備配置資料表包含軟體模組和與模組相關聯的各種屬性的列表。它也可以表明模組的分類是元件還是功能性。

這裏描述的是基於XML的軟體模組屬性的規範，它可以提供公共的、可移植的語言來詳細說明(H(e)NB)的元件和/或模組，以及相關聯的屬性。為了用可移植的方法和與H(e)NB結構無關的方式提供資訊，需要演變出一種具體說明模組的語言。這種語言可以與包含了XML概要和XML檔的XML語言類似。模組的格式和各種屬性可以進行標準化，並且每個製造商用前面描述的格式提供描述軟體模組的設備配置資料表。格式可以與XML概要類似，並且設備配置資料表可以與XML檔類似。XML 簽名支援增加數位簽名來提供完整性、訊息鑑定和/或簽名者鑑定。二進位XML是一種更緊湊的描述，並且它也可以作為減少語法開銷以及減少在實體之間傳遞配置資料的帶寬需求的基礎。表4中給出了一個XML概要的實例，可以是製造商用來詳細描述他們模組的標準格式。

製造商可以提供設備配置資料表並用數位簽名進行簽名。設備配置資料表可以在H(e)NB上維護以用於AuV。在校驗失敗的情況下，如果設備配置表的數位簽名本身驗證通過，可以採取適當的措施，因為這表明軟體的屬性、包括對失敗模組的影響的資訊，是完整無損的，儘管軟體模組本身(即二進位影像(image))可能已經改變或者完整性校驗失敗。在使用SAV的情況下，設備配置表需要在設備和PVE上進行維護。為了支援SAV，需要增加本文描述的額外的行動。

這裏描述的是基於ASN.1的軟體模組屬性的規範，它可以提供公共的、可移植的語言來詳細描述H(e)NB的元件及相關聯的屬性。在電信和電腦網路中，ASN.1是一種標準的、靈活的定義，它描述了用於表示、編碼、傳輸和解碼資料的資料結構。它可以提供一組獨立於機器特定編碼技術之外的、用於描述物件結構的正式規則，並且它是一種消除了歧義的準確的、正式的定義。通常用於定義通信協定訊息、ASN.1及其相關聯的編碼規則，是一種二進位編碼方式。其他通信協定、例如網際網路協定HTTP和SMTP，定義了使用文字標記和值的訊息，有時是基於擴展巴克斯-諾爾範式(ABNF)定義。這個定義也用文字的形式定義了編碼。

ASN.1方法被認為更有效，以及與壓縮編碼規則一起，當然就提供了一種更緊湊的編碼方式。這種文字方法宣稱更容易實施(通過建立和解析文字字串)和更容易除錯，因為可以簡單地讀懂編碼的訊息。在媒體閘道協定中，定義了兩種基於ASN.1和ABNF的編碼。

ASN.1 XML編碼規則(XER)提供了一種定義了使用ASN.1定義的資料結構的文字編碼。通用字串編碼規則也是為了給/從使用者顯示和輸入資料的唯一目的而定義的。表5給出了一個用於傳遞設備完整性度量的ASN.1的實例。

如果對於設備的每一個軟體模組，它的相關聯的模組屬性網路都知道，則在SAV過程中，H(e)NB可以只向PVE發送所有在本地完整性校驗過程中完整性校驗失敗的模組的標識(ID)列表。網路通過PVE可以知道特定軟體模組的相關屬性和它們失敗的影響。這個資訊可用於評估網路採取的下一個步驟，如本文描述的一樣。

這裏描述的是軟體模組屬性，它們可以被認為是傳送至H(e)NB的並且可以作為來自可信的第三方(TTP)、如H(e)NB管理系統(H(e)MS)的數位證書或簽名訊息來提供。例如，編碼影像的總體資訊元素可以包括但不局限於H(e)NB的製造商以及可用於產生模組編碼影像的摘要或RIM的完整性方法。

這裏描述的是描述元件特定資訊的方法。一個或多個元件組成了軟體模組。元件是完整性校驗的基本單元。每一個元件關聯有一個可信的參考值(TRV)。元件特定的資訊元素可以包括元件ID，元件ID是與元件描述有關的唯一可識別的ID。這是用一個TRV進行校驗的編碼單元的ID。它還可進一步包括TRV，TRV被H(e)NB的完整性校驗機制用來比較元件的測量結果以驗證元件的完整性。

模組特定的資訊元素可以包括但不局限於在H(e)NB中描述特定模組功能的模組描述以及為製造商唯一地標識模組的模組ID。它也可以包括指明了該模組映射到H(e)NB的哪一個特定功能性的功能描述以及功能ID，該功能ID可以是全球可識別的ID，由賣方制定標準並與該功能描述一致。它還可以進一步包括標識了該模組映射到哪一個元件的元件ID以及指示了模組的版本號的發佈版本。在元件和模組是一對一映射的情況下，模組特定的資訊實際上和元件特定的資訊是相同的。

模組特定的資訊元素還可以包括嚴重性分級(classification)，該分級指明了當前軟體完整性校驗失敗對系統功能性的影響。例如，可以有多層次的嚴重性分級系統。例如，嚴重性1可以是導致對H(e)NB功能性有高影響並有必要終止系統操作的模組/功能的失敗。模組/功能的失敗會導致基於回退編碼影像(FBC)的蹣跚(limp along)系統。在這種情況下，與基於網路的設備管理系統(如果設備是H(e)NB，該系統會是H(e)MS)通信是可能的。FBC能給指定的H(e)MS發送遇險信號。更進一步地，FBC還能支援網路發起的韌體/軟體更新。例如， H(e)NB的可信的環境(TrE)的任何模組或元件會具有嚴重性1。嚴重性2可以是導致H(e)NB功能性受限的模組/功能失敗，可以部分地起作用或者支援全部H(e)NB功能性的子集。這種情況下，與安全閘道(SeGW)通信是可能的。嚴重性3可以是不會影響系統的核心功能性、但在失敗的情況下仍會被認為足夠重要而需要提早補救的模組/功能的失敗。失敗的模組/功能可以通過用立即的韌體/軟體更新過程來替換並通過隨後的重新啟動生效。嚴重性4可以是不影響系統的核心功能性的模組的失敗。失敗的模組可以通過常態的韌體/軟體更新調度進行替換。

這裏描述的是確認方法的報告過程或方法。對於AuV，設備完整性校驗的所有過程都可在本地進行。如果完整性校驗失敗，則需要向H(e)MS發送遇險信號以指示該失敗。隨後的操作可以從派遣人員到解決該問題或檢測該設備。可以進行補救，這種情況下失敗模組的列表需要報告給補救伺服器/H(e)MS。對於SAV，完整性校驗失敗的功能性的列表要報告給PVE。

模組依賴於製造商的應用。一組編譯過的軟體模組可能會形成物件影像。完整性校驗可以針對物件影像塊(chunk)進行。因此，引入了元件，元件將進行完整性校驗的一組模組結合起來。一個模組在一個元件中只出現一次並且只出現在一個元件中(即一個模組不能出現在兩個元件中)。這樣，當進行完整性校驗時，一個模組只被校驗一次。H(e)NB的製造商(可能與任一軟體模組的製造商相同或不同)根據架構來決定如何將模組分割成元件以進行設備完整性校驗。

功能性可以基於H(e)NB的需求和功能架構，而且可以是標準化的識別字。例如，Iu介面和移動性管理就是功能。兩個功能可以共用一個模組。因此，在一個元件(完整性校驗量子)的完整性校驗失敗時，就知道了受影響的模組。由於每個模組有與其關聯的功能性，因此會得出失敗的功能性的列表。SAV中，這個失敗的功能性的列表被發送到PVE。

這裏描述的是功能性ID。該架構的使用管理著軟體模組的數量和類型。為了通過多個製造商和/或利益相關者(如移動網路運營商)協調報告結構和方法，報告可以基於功能性而不是實際的模組。軟體模組可以根據其功能性來進行分組。功能性ID提供了根據功能性描述將模組進行分類的方法。表6列出了一些根據目前已知的推導出的功能性。該列表可以被擴展和標準化。表6中，低位元數位1-9是為將來使用或擴展預留的。

這裏描述的是組件ID。為了協調設備完性校驗，這些模組可以根據產生的影像進行分類。一組物件檔集可一併存檔到一個影像檔中。這樣一組模組包含同一元件ID並共同進行完整性校驗，因此，一個元件有一個可信的參考值(TRV)。由於每個軟體模組都有自己的參考完整性度量(RIM)，因此元件的可信的參考值(TRV)可以作為一個或多個軟體模組的一系列的摘要(例如，廢料)而獲得，每個模組都有與之相關聯的RIM。請注意，在一個元件ID中出現的模組可能被映射到不同的功能性ID而不是相同模組出現在另一個元件ID中。該過程給製造商根據他們的架構和編譯器提供了靈活性，例如，使基於物件影像或者SAV完整性校驗的步驟進行模組分組變成可能。

模組ID用於跟蹤軟體不同的模組，並且可能不需要進行標準化，儘管不是不可能標準化。如果模組ID沒有被標準化，會留給製造商來決定存在哪些和存在多少模組。模組ID可用來提供、跟蹤和構造韌體/軟體更新包。這裏描述的是組織和陳述各種識別字例如模組、元件和功能性之間關係的方法和結構。第1圖示出了一個示例性方法和結構。軟體架構定義了模組的數量和類型。這些模組根據其功能性和完整性校驗量子進行分類。由多個模組組成的元件有它自己的TRV。如果任何元件使用它的TRV進行的完整性校驗失敗了，那麼要麼元件本身被更改了，或者其摘要已不再與TRV相同了，或者與組件一致的TRV被更改了。任何情況下，一旦完整性校驗失敗，模組和完整性校驗失敗的元件之間的映射以及模組和功能性之間的映射會被用來確定失敗的(至少是“受影響的”)功能性的列表。受影響的功能性的識別字的列表被傳遞到H(e)MS或者PVE。

第2圖示出了組件和功能性的示例性結構。如圖所示，當這些元件是進行完整性校驗的單元時，元件可能由製造商決定。每一個元件都要與一個功能性列表相關聯。這些組件是基於這些功能性的。因此，當一個元件的完整性校驗失敗，失敗的功能性的列表會被建立。這些元件可以按其載入順序或者可替換地按照其執行的順序進行組織。因此，如果元件1校驗失敗，則使用了來自元件1的功能的元件2的功能性不管是載入還是執行也會失敗。

另一種替換的根據失敗的完整性校驗提取失敗的功能性的列表的應用可以在成塊的影像物件檔上進行完整性校驗。如果某個由物件影像中的起始位址和結束位址指定的影像塊沒有通過完整性校驗，則與該失敗的分段對應的軟體功能的名稱會被提取出來。根據應用的功能，失敗的H(e)NB功能性的列表會被推導出來。可以這樣做是因為軟體功能屬於應用了某些H(e)NB功能性的模組。例如，在UNIX環境下‘nm’提供了提取物件檔中的功能的名稱的功能性。這個資訊是提取自該物件的符號表的。

這裏描述的是用於確認方法的軟體和TRV的下載或提供。可用的三種協議是基於TR069的架構、基於開放移動聯盟(OMA)設備管理(DM)的架構和基於可信的計算組(TCG)基礎結構工作組(IWG)的架構。另外這些協議也可以通過利用提供的支援來配置H(e)NB。除了這三種之外，也可以考慮其他的協議。

第3圖中基於TR069的架構描述了使用者端設備(CPE)廣域網(WAN)管理協定，它是用於CPE和自動配置伺服器(ACS)之間的通信的。CPE映射到H(e)NB，並且ACS映射到H(e)MS/補救伺服器/操作、管理和維護(OAM)。該CPE WAN管理協定可以提供工具來管理CPE軟體/韌體影像文件的下載。該協議可以提供版本識別機制、檔下載啟動(ACS發起的下載和可選的CPE發起的下載)、以及檔下載成功或失敗的ACS的通知。

CPE WAN管理協定也可定義數位簽名的檔格式，它可選擇地被用於下載個別檔或一包檔，與供CPE執行的顯式的安裝指南一起。簽名的包格式確保了下載檔和相關安裝指南的完整性，允許檔源的鑑定可能是除了ACS操作員之外的一方。下載的檔的完整性校驗可以建立在將從包含在下載的檔中的各個模組計算得到的完整性摘要(如廢料)與它們對應的RIM值比較的基礎上。

CPE WAN管理協議可能對H(e)NB的設備完整性校驗需要的TRV的下載是有用的。這些內容可以用網路運營商的簽名密鑰進行數位簽名。一旦接收到簽名的資料包，H(e)NB然後可以解密簽名並且驗證收到的TRV的可靠性和完整性。當元件是由按順序的幾個模組級聯而成時，TRV可以按照與這些模組對應的RIM的順序級聯而建立。

TRV也可以在數位簽名前為了安全性而進行加密。它們也可能被添加到同一數位簽名包中TRV建立的軟體模組二進位影像的全部或(第一或最後)部分中。

這裏描述的是處理H(e)NB設備的額外的過程。這些額外的需求和過程可以使用介面標識，就像下文描述的H(e)NB-H(e)MS介面一樣。H(e)NB的確認可能需要額外的協定元件需求。H(e)NB-H(e)MS應當支持安全插口層/傳輸層安全性(SSL/TLS)並使用基於證書的H(e)NB和H(e)MS之間的鑑定。這個證書可以與用於SeGW鑑定的證書是相同的。如果H(e)NB-H(e)MS介面使用的是基於TR069的架構，則需要採用CPE鑑定的基本或摘要鑑定來支持基於證書的鑑定。

這裏描述的是基於TR069架構的H(e)MS發現可能需要的過程或結構。H(e)NB應以ManagementServer.URL(管理伺服器.URL)參數中一個系統預設H(e)MS統一資源定位器(URL)進行配置。這個初始化配置可以由運營商在佈置H(e)NB的時候完成或者由製造商完成。H(e)NB可支援局域網(LAN)側的通過鑑定的管理員進行的ManagementServer.URL配置。H(e)MS URL可以是超文字傳輸協定安全(HTTPS)URL。主機側基於動態主機配置協定(DHCP)的H(e)MS URL更新過程可以不需要支援。如果該值在本地更新，則H(e)NB可以聯繫新的H(e)MS來揭開(bootstrap)配置檔並建立關係。該URL可以是名稱或者網際網路協議(IP)位址，它可能需要功能變數名稱系統(DNS)解析。名稱的DNS解析可能會返回多個IP位址，這種情況下它或者需要確保不會返回多個IP或者如果返回多個IP則H(e)NB從中任意選擇一個。

這裏描述的是基於TR069架構的SeGW發現。類似於H(e)MS URL，SeGW URL可以作為參數(SecureGateway.URL(安全閘道.URL))來增加。該URL可以由運營商根據H(e)NB的位置來配置。通過DHCP更新這個參數可以不被支持。經授權的管理員可以進行本地更新。

為了AuV和SAV，為適應設備管理協定的其他機制、諸如TR069、OMA DM、或TCG IWG在下文中描述。

這裏描述的是基於OMA DM的架構，用於下載和提供軟體和用於確認方法的TRV。OMA DM是由OMA DM工作組和資料同步(DS)工作組聯合指定的設備管理協定。雖然OMD DM是為像電話、PDA和其他類似設備的小型移動設備而開發的，它不支援設備和DM伺服器之間的寬頻有線連接，只支援短距離有線連接(例如，通用串列匯流排(USB)或RS232C)或無線連接(全球移動通信系統(GSM)、碼分多址存取(CDMA)、無線區域網路(WLAN)和其他無線通信系統)，它可以用於作為為H(e)NB提供和管理協定的設備。當H(e)NB相對於核心網路把自己當成無線發射接收單元(WTRU)而相對於通用串列閘道(CSG)把自己當成基地台並且沒有CSG WTRU與它相連時，這可能成為現實。

OMA DM可以支援使用諸如提供(包括首次設備配置和使能/禁用特徵)、設備配置更新、軟體升級以及診斷報告和查詢的情況。OMA DM伺服器端可支援所有這些功能，儘管該設備可以選擇性地應用這些特徵的全部或子集。

OMA規範可以進行優化以支援上述所列的有連接限制的小型設備的特徵。它也可支持完整性安全、使用鑑定(通過使用例如可擴展鑑定協議-鑑定和密鑰協商(EAP-AKA))協定作為規範的一部分。

OMA DM可使用XML(或者更確切地說，來自SyncML的子集)進行資料交換。為了確認的目的，這可能對為H(e)NB的軟體模組或功能性提供一種可標準化的且靈活的方式來定義和傳遞屬性是有用的。

設備管理發生在DM伺服器(設備的管理實體)和使用者端(被管理的設備)之間。OMA DM支援傳輸層、如無線應用協定(WAP)、HTTP或物件交換(OBEX)或類似的傳輸。

DM通信是由DM伺服器使用任何可用的方法例如WAP、Push(推送)或短訊息服務(SMS)、使用通知或警告資訊非同步發起的。一旦通信在伺服器和使用者端之間建立起來，就會通過交換一系列訊息來完成給定的DM任務。

OMA DM通信可以基於請求-回應協議，其中請求只能由DM伺服器發出，且使用者端可以用應答訊息進行回應。伺服器和使用者端都是有狀態的，這意味著任何由於特定的順序的資料交換只能發生在內置的鑑定過程之後。

由於DM通信只能由DM伺服器發起，在DM上應用SAV可能需要基於伺服器請求的方法來確認，可能(立即)繼設備鑑定過程之後使用網際網路密鑰交換(IKE)v2(這是由設備啟動的)。幾種不同類型的訊息可以考慮作為傳遞確認資料(例如，失敗的軟體模組或設備功能性的列表)。例如，管理警告訊息可從設備發送到伺服器。可替換地，自設備或者伺服器至少傳輸了一個管理警告資訊之後，可以由設備發給DM伺服器的通用警告訊息的使用者也是可以考慮的。由於所有訊息、包括這些警告訊息使用了同步標記語言(SyncML)格式，該格式在詳細描述內容和內容的元資料時提供了靈活性，因此它可用於確認資訊傳輸。

DM可以支援分段資料的傳輸，這可用於更新的大小比較大時的軟體更新。當從H(e)NB傳輸到PVE的失敗的功能性的列表資訊的大小足夠大以至於需要分成多個訊息時，分段資料傳輸也可用於傳輸這樣的列表。這裏描述的是基於TCG IWG的架構，它用於下載和提供軟體以及用於確認方法的TRV。可信的計算組(TCG)、基礎結構工作組(IWG)已詳細描述了用於平台完整性管理的詳細格式和協議。在完整性測量和報告的基本模型中，網路和服務存取可以取決於平台的驗證狀態。

TCG IWG標準提供了一個H(e)NB SAV或 AuV需要的結構的超集合。沒有IWG規範可以現成使用的。此外，將IWG規範用於設備確認的特定用途的情況需要對XML概要進行修改(如略去需要的元素)，這意味著偏離了IWG標準。

第4圖示出了請求的平台和網路側驗證者之間的基本交互。驗證者需要對請求者的平台的每一個元件尋找鑑定資訊(在第五步)。也就是說，為了由度量提供者變成可用的平台確認，需要參考測量。度量提供者的實例有硬體製造商、軟體供應商或代表製造商和供應商的可信的供應者。一旦驗證者能夠識別每個請求者的平台的元件，並將報告的測量值與預期的(基準)參考測量值(該元件的)進行比較，驗證者就能衡量請求者的平台的信任級別。在這個階段，驗證者能根據請求者在可信賴方對存取資源/服務的願望做出決定。這在第六步中示出。

需要注意的是IWG完整性驗證架構在很大程度上是獨立於驗證過的平台上的硬體可信的平台模組(TPM)的存在的。尤其是在標準中的資料格式有能力表達通用元件和平台安全相關的屬性。

為了支援給定元件內的技術上的信任，元件製造商可能會以其元件來源相關的資訊支援他的產品。也就是說，製造商或可信的第三方必須提供一些該元件的靜態參考值。元件的這些靜態參考/度量值被稱為參考測量，並用TCG參考清單(RM)結構的形式表示。元件的清單包含諸如其身份(identity)、製造商、型號、版本號等等的資訊。就本申請而言，H(e)NB元件的可信的參考值(TRV)可以由TCG IWG參考清單(RM)結構詳細描述。

當平台需要得到確認，它必須向確認者(如平台驗證實體-PVE)提供完整性報告，該完整性報告是從如第5圖中所示的覆蓋了平台組件的一組快照編譯而成的。所述快照表示關於平台的每一個相關元件(可能是這些元件的子元件)的測量和斷言(assertion)。參考(ID參考)被用來指向屬於如第6圖中所示的完整性報告中報告的元件的資訊。

基於RM的用於確認的核心元件是在TCG標準中描述的。為了靈活性，XML命名空間(namespace)可用於IWG格式的平台特定的文檔(profile)，例如移動或PC使用者端。

可共用的完整性日誌結構通過定義“硬體架構”類型值來指示平台特定的編碼方式可以解決一些平台特定的限制。類型值可以通過使用可共用的命名空間機制例如XML命名空間和XRI，用TCG命名空間的形式來定義。

從核心概要擴展繼承而來的RM概要，定義了結構以保持參考。該RM概要可大體理解為由如第7圖所示的兩組資訊組成。第一個屬於關於各個元件的資訊，並涵蓋了諸如元件模型、名稱、版本、序列號等屬性。該資訊是在ComponentIDtype(元件ID類型)結構中捕獲的。圍繞著該元件特定的資訊的是屬於捕獲(收穫)元件資訊的元資料。這由概要中IntegrityManifestType(完整性清單類型)結構表示。捕獲的元資料包括使用的收集者(收穫者)方法、RM簽名(以及相關簽名者/發行者資訊)、元件(軟體的)的概要值、信任等級、斷言進行以及其他。

這裏描述的是AuV特定的項目。在AuV中，完整性校驗可在本地進行。因此，任何本文描述的數位簽名或訊息鑑定碼都可以使用。這些可以由製造商使用製造商的私有密鑰/共用的秘密來簽名，並且可以使用製造商共用的秘密或公開的密鑰來為他們的可靠性進行本地驗證，以及可用於本地編碼的完整性確認。

然而，在AuV中，設備的驗證可在設備中本地執行，並且資訊不被發送到任何網路實體。因此，可能會留給製造商來決定確切的用於確認的的方法。不過，最低限度的安全需求可以進行標準化，如‘完整性演算法必須提供等於或優於SHA-1的安全性。

這裏描述的是AuV怎樣應用TRV證書管理。由於系統的元件依賴於實際的應用，有必要統一設備完整性使用的機制。這可以通過標準化用於產生被稱為TRV的可信的參考完整性度量的方法的最低要求來實現。這些TRV可由生產商產生或由對該值進行數位簽名的TTP產生。因此，回顧一下組織資訊、產生TRV、發佈並使用它們的機制。

這裏描述的是首次TRV認證初始化(initialization)。在完成H(e)NB開發之後，製造商執行本地完整性資料初始化。在這個過程中，所有的軟體模組的名稱被收集在設備配置資料表中。如果存在任何與配置檔有關的工廠設置，它們也被包含在設備配置資料表中。這些模組是可執行的，而不是源代碼。也進行配置資料提供的發起。設備配置資料表概要緊跟標準概要。本文描述的XML或者ASN.1概要可以作為基準使用。所有關於嚴重性、相容性、步驟和其他的屬性都是根據設備的結構填充(populate)的。

第8圖示出了證書管理架構800。在製造商的認證伺服器805中，所有模組實體810是用參考完整性度量填充的。完整性方法屬性和TRV屬性被填充。設備配置資料表然後由製造商使用私有密鑰820進行簽名。它也可以用由TTP發佈給製造商的根證書進行認證。由此，參考完整性度量(RIM)變成了TRV 830。

在一個替換架構中，TRV可以由TTP產生。製造商提供可執行的及部分完成的設備配置表，該表列出了所有的模組和一些可在製造商方填入(fill)的填充的屬性。是概要度量的TRV由TTP填充。然後TTP對設備配置證書進行數位簽名。

設備配置資料表可在設備中進行維護，因為AuV是在設備中本地進行的。該設備配置資料表必須保存在只能由鑑定的一方存取的安全記憶體中。可替換地，設備配置資料表必須被加密，它在H(e)NB中進行讀取和使用時可以被解密。在這兩種情況下，只有H(e)NB的可信的環境(TrE)有權發佈用於由應用讀取存取的設備配置資料表或修改它。

在安全啟動過程中，當設備執行元件的本地測量時，產生的摘要會與設備配置資料表中指定的值進行比較。如果發生不匹配則被解釋為設備完整性確認失敗。設備配置資料表的完整性必須在它被存取之前得到確認。設備配置資料表的完整性也可以在資料表中描述的任何一個或多個元件的一個或多個完整性校驗失敗之後進行確認。這裏描述的是隨後的TRV證書更新過程。對於部署好的H(e)NB系統，如果製造商發佈了一個新的軟體版本，那麼製造商會在提供軟體模組給H(e)MS/OAM伺服器/補救伺服器的同時提供該設備配置資料表。這可以由製造商通過執行‘PUSH(推送)’操作非同步完成。這樣的PUSH可以根據運營商和製造商之間達成一致的預定的更新/升級進行調度，這些更新/升級是基於運營商和製造商之間簽訂的服務協定的。

這樣的PUSH之後，用於更新韌體或軟體模組的OAM過程或TR069過程可能會被調用(invoke)，這指示設備在預定的時間重新啟動以從H(e)MS/OAM/補救伺服器執行‘PULL’操作軟體/韌體。加密、簽名以及亂數可以分別提供諸如保密性、完整性和重放保護的安全方式。

可替換地，當設備配置資料表由於根據軟體發佈時間表的預定期滿而期滿時，H(e)NB會啟動韌體/軟體更新過程，並從OAM/補救伺服器針對軟體/韌體開始PULL操作。可替換地，H(e)MS可以根據已知的時刻表(例如從製造商處獲取的)執行軟體更新的預定的PUSH操作。

這裏描述的基於TR069或OMA DM架構的過程支援軟體/韌體下載到設備。在AuV的情況下，TR069協定可以提供對使用者端設備的遠端管理支援。它也可以提供對設備軟體/韌體更新的支援。TR069可用於提供韌體/軟體更新到H(e)NB設備。

這裏描述的是為隨後的更新而在H(e)NB 905和H(e)MS 910之間進行的AuV過程實例，這些隨後的更新如第9圖所示，可以在H(e)NB 905上由經過授權的管理員或者通過利用URL更新過程來執行。H(e)NB 905被用如前文描述的關於H(e)MS發現的ManagementServer.URL參數(0)中的系統預設H(e)MS統一資源定位器(URL)進行初始化配置。這可能由製造商提供。H(e)MS 910打開傳輸控制協定(TCP)連接(1)。在H(e)NB 905和H(e)MS 910之間建立起安全插口層(SSL)連接以允許安全通信(2)。H(e)MS 910發起遠程程序呼叫(RPC)方法設置參數值(SetParameterValue)並更新ManagementServer.URL(3)。在成功更新後，H(e)NB 905以指示成功或失敗的狀態欄位發送設置參數值回應(SetParameterValuesResponse)(4)。H(e)NB 905更新H(e)MS URL(5)。

這裏描述的是為支援檔傳輸使用H(e)NB-H(e)MS介面的TR069的AuV過程。TR069支援通過單播和多播傳輸協議進行檔傳輸。單播協定包括HTTP/HTTPS、檔傳輸協議(FTP)、安全檔傳輸協議(SFTP)和普通檔傳輸協議(TFTP)。多播協議包括通過單向傳輸的檔傳遞(FLUTE)和數位儲存媒體命令和控制(DSM-CC)。對HTTP/HTTPS的支持是必選的。為了使TR069適應H(e)NB-H(e)MS介面中的韌體/軟體下載，除了HTTP/HTTPS，FTP安全(FTPS)也可以使用並需要加到TR069中。FTPS(也稱為FTP安全和FTP-SSL)是FTP的擴展，它增加了對傳輸層安全性(TLS)和SSL加密協定的支援。由於H(e)NB-H(e)MS介面使用了TLS-SSL介面，FTPS可應用於傳輸文件。

TR069也提供了對為下載檔重利用相同的TLS連接、為下載檔產生一個新的連接的支援，後一種情況可能存在於平行或發佈第一個會話時。下載完成之後，信令的TLS連接被建立。如果HTTP/HTTPS被用於下載檔，則可以使用標準的TR069過程。

這裏描述的是支援補救的AuV過程實例。如果AuV中設備完整性校驗失敗了，則本地遇險標誌被設置並且該系統重新啟動後備代碼(FBC)。FBC可以安全地儲存在設備中，如果安全啟動過程(或設備的任何其他被認為是對確保設備的基本完整性‘必不可少’的過程)失敗，FBC會被載入和執行。FBC有與核心網路進行基本通信的能力和有向預先指定的H(e)MS發送遇險信號的能力。H(e)MS可以已經由H(e)MS發現過程進行了更新。遇險信號的內容可以安全地儲存在設備上的FBC內，或者由MNO提供並作為設備配置資料表的一部分進行安全儲存。遇險信號可以包含指示設備完整性校驗失敗的具體資訊的錯誤代碼資訊元素。一旦接收到遇險信號，網路會決定更新完整的影像和包含了可信的參考值的設備配置檔。FTP伺服器儲存了包含完整影像的包檔、設備配置檔和安裝指南。該FTP伺服器可以與H(e)MS進行合併。

該過程可以通過FBC支援TR069協議取得，第10圖示出了H(e)NB 1005、H(e)MS 1010和FTP伺服器1015之間的流程圖的實例。如果設備完整性校驗失敗且信任根(RoT)已經在H(e)NB 1005上啟動了FBC(0)，則H(e)NB 1005與預先指定的H(e)MS伺服器1010建立TCP連接(1)。執行SSL初始化和/或建立傳輸層安全性(TLS)(2)。H(e)NB 1005然後調用RPC方法INFORM、例如遇險信號給H(e)MS 1010。遇險信號可以包含任何資訊元素、例如設備ID(Device ID)、事件(Event)、最大包絡(MaxEnvelopes)和當前時間(CurrentTime)的組合。

設備ID(Device ID)是一個結構，該結構可以包含製造商名稱；設備製造商的組織唯一識別字(OUI)；產品分類(ProductClass)，可用於指示使用序列號的產品的分類或者用於為了讓序列號(SerialNumber)屬性被用於指示TrE ID或H(e)NB ID而指示設備的序列號；以及序列號，可用於發送特定設備的序列號或者發送TrE ID或H(e)NB ID。

事件(Event)欄位可以包含引起執行的RPC方法通知的事件代碼。可能需要定義一個新的事件代碼(X_HeNB_FBC調用)來指示設備完整性校驗已經失敗以及FBC已經被調用以發送該遇險信號。用以向ACS(例如H(e)MS)指示可能被包含在單個HTTP回應中的叫做“SOAP包絡”的參數的最大發生次數的最大包絡值，可以被設為1。參數最大包絡(MaxEnvelope)的值可以是1或者更大。由於遇險指示傾向於只發送一次，將該值設為1是合適的。當前時間(CurrentTime)欄位是H(e)NB1005 知道的當前日期和時間的值。因此，該通知(Inform)RPC方法向H(e)MS 1010指示了設備完整性校驗已經失敗並且正在為初始化韌體/軟體更新進行連接。

餘下的過程1000是可選的。H(e)MS 1010可以調用RPC方法下載並且提供韌體或者軟體位置的URL和設備配置資料表(4)。下面的參數值需要設置。CommandKey(命令密鑰)參數是一個可能會被H(e)NB 1005用來指示特定下載的字串。這可以是用於使下載和回應相關聯的任何字串。FileType(檔類型)參數可以針對韌體/軟體影像被設置為“1 Firmware Upgrade Image(韌體升級影像)”以及針對設備配置資料表被設置為“X_<OUI>_data_sheet(X_<OUI>_數據_表)”。URL參數是下載文件的URL。HTTP和HTTPS必須被支持。針對下載也推薦支持FTPS。使用者名(Username)參數可以被H(e)NB 1005用來鑑定檔伺服器。密碼(Password)參數可以被H(e)NB 1005用來鑑定檔伺服器。FileSize(文件大小)參數是要下載的文件的大小。還可以設置其他參數。

H(e)NB 1005連接到FTP伺服器1015並且下載韌體影像(或軟體影像)和設備配置資料表(5)。FTP伺服器1015上的資訊可以表示成補救資訊。一旦成功完成下載，就發送一個具有值設為0(表示成功)的狀態參數的下載回應(DownloadResponse)，或者一個下載請求的錯誤回應(表示失敗)(6)。也可以接著用替換過程來指示成功或者失敗的下載。在成功的下載回應之後，H(e)MS 1010則調用H(e)NB 1005中的重新啟動過程(7)

H(e)NB 1005中的RPC處理器重置本地遇險標誌並正常啟動以執行本地完整性校驗過程(8)。簽名的包格式可能包括重新啟動命令，它可用來指示H(e)NB 1005在韌體或者軟體更新之後進行重新啟動。傳輸完成(TransferComplete)RPC方法可以從H(e)NB 1005被調用以指示H(e)MS 1010韌體/軟體更新過程已經成功完成(9)。可替換地，SeGW可以向H(e)MS 1010發送訊息以指示設備已經成功啟動，這在H(e)MS 1010中會被解釋為成功的韌體/軟體更新完成訊息。

這裏描述的是一個可用於H(e)NB韌體/軟體更新的檔格式1100的實例，在第11圖中示出。報頭1105可以是一個固定長度的結構，包括前同步碼、格式版本和命令列表和負載(payload)元件的長度。命令列表1110包含可被執行以提取和安裝包含在包中的檔的指令序列。每一個命令都可以是類型-長度-值(TLV)的形式。簽名欄位1115可以包含公共密鑰加密標準(PKCS)#7數位簽名塊，該數位簽名塊可能包含了一組0或者更多數位簽名。負載檔1120可能包括要按照命令列表1110中的指令進行安裝的一個或多個檔。除了韌體/軟體更新檔外，設備配置資料表也用簽名包格式進行打包。

為了支援儲存分類器的需求，可以增加下列新的H(e)NB特定的命令：1)儲存到安全非易失性記憶體中(針對諸如TRV或者配置資料表之類的資料)；以及2)儲存到非易失性儲存器中；或者3)可以儲存到易失性儲存器中。

第12圖示出了SAV的網路架構1200的實例。H(e)NB 1205作為使用者設備1210通過通信鏈路1215與核心網路1220通信的閘道。H(e)NB 1205與SeGW 1225通過不安全的通信鏈路1215相互配合。SeGW 1225可以允許通過鑑定的H(e)NB存取到核心網路1220。H(e)MS 1230作為H(e)NB管理伺服器並提供對補救的支援。H(e)MS 1230可以支援標準的協定來管理H(e)NB 1205。平台確認實體(PVE)1235儲存了當H(e)NB 1205中的某一組功能性失敗時需要採取的行動的策略。失敗的功能性由H(e)NB 1205在SAV過程中報告。OAM 1240是操作、行政和管理伺服器。儘管H(e)MS 1230和PVE 1235是作為分開的實體顯示的，但它們可以合併成一個單獨的網路實體。這樣一個合併的實體可以是每個網路運營商的一個節點或者可以是每個運營商多個節點。

這裏描述的是關於SAV的過程。總的來說，在執行設備鑑定過程之前，H(e)NB的TrE首先進行某些預先指定的元件的完整性校驗，這些元件例如但不局限於啟動代碼、後備代碼(FBC)、SeGW的基本通信代碼以及執行使H(e)NB存取到H(e)MS的過程的代碼。在這一步中，元件完整性的驗證可以通過將來自完整性測量的概要輸出與設備配置資料表中指定的值進行比較而本地進行。如果元件通過了完整性驗證，則他們被裝載和執行。

進一步的校驗可以通過TrE本身或者通過外在於TrE的H(e)NB中的測量元件進行，但由TrE保證完整性。在這些後面的步驟校驗中，其他元件、配置或者重置H(e)NB的參數在被載入或者啟動時、或者在其他預定義即時時間事件、不管在哪里只要這些對測量元件是可用的，都會被校驗完整性。在這一步中，完整性校驗的驗證可以在本地進行。

H(e)NB然後會嘗試與SeGW建立網際網路密鑰交換(IKEv2)安全聯盟。在該過程中，H(e)NB將自己向SeGW進行鑑定並且驗證SeGW的可靠性(authenticity)。這可以通過證書交換和證書鑑定來進行。如果鑑定成功，則TrE通過彙編受元件失敗影響的失敗的功能性的列表將本地完整性驗證的結果傳達給PVE。TrE然後對訊息(使用受TrE保護的簽名密鑰，以保護訊息的完整性)簽名，該訊息斷言了進行完整性測量和驗證的H(e)NB的核心部分以及(向PVE)報告的(向PVE)失敗的功能性的列表已經通過了它上面進行的(例如通過信任根(RoT))完整性校驗並且因此已經能使用簽名密鑰並執行簽名操作，或者通過使用秘密簽名密鑰進行其他的本身可信的操作。

第13A圖和第13B圖示出了一個用H(e)NB 1305、SeGW 1310和PVE 1315進行的SAV過程1300的實例。在元件1和元件2模組的本地完整性驗證之後，這些模組被載入和執行。元件3模組的設備完整性校驗的結果和驗證結果由H(e)NB 1305發送給SeGW 1310以轉發給PVE 1315(0)。

H(e)NB 1305可以發送IKE_INIT訊息以啟動建立包含了加密演算法的安全參數索引、版本號、IKEv2標誌、Diffie-Hellman值以及初始值亂數的IKEv2安全聯盟(1)。SeGW 1310可以發送IKE_INIT回應給IKE_INIT請求訊息(2)。SeGW 1310可以從H(e)NB 1305選擇加密套件並完成Diffie-Hellman交換。H(e)NB 1305可以為相互鑑定而以IKE_AUTH_REQ發送其證書(3)。它也可以包括形式為失敗的功能性的列表的完整性驗證結果。如果本地完整性驗證成功，則不包括這個失敗的功能性的列表。這種情況下就發送空列表。這裏描述了元件、模組和功能性之間的關係。

SeGW 1310可以評估H(e)NB 1305的鑑定憑證並提取將要發送給PVE 1315的功能性ID的列表，如果該列表存在的話(4)。如果鑑定評估成功，則SeGW 1310將其指示給H(e)NB 1305(5s)。它也可以將它自己的證書在回應中發送給H(e)NB。如果鑑定失敗，則就傳遞給H(e)NB 1305(5f)。

如果鑑定成功，並且失敗的功能性的列表被包含在IKE_AUTH訊息中，則SeGW 1310將該失敗的功能性的列表與H(e)NB ID一起轉發給PVE 1315(6)。如果該列表不存在，就向PVE 1315發送一個空的列表。根據該失敗的功能性的列表，PVE 1315可以決定將採取的行動、例如隔離設備、提供完全存取、提供部分存取或者可選擇地請求H(e)MS干涉以進行設備補救(7)。如果PVE 1315決定受影響的功能性不重要並且因此H(e)NB 1305可以工作，則將該決定指示給SeGW 1310以允許設備存取網路(8s)。SeGW 1310指示由PVE 1315進行的設備完整性評估的結果。如果失敗的模組不重要，則PVE 1315就允許H(e)NB 1305完全存取到網路中(9s)。完全地或者部分地根據接收到的空的失敗的功能性的列表，如果PVE 1315決定H(e)NB應該能足夠被信任用於鑑定，則會獲得H(e)NB的‘確認’的狀態。在這種意義上，確認被解釋為由PVE 1315從網路的角度作出的指示H(e)NB 1305值得足夠信任來進一步與之交互的決定。

如果支援補救，則PVE 1315通過訊息發送指示給H(e)MS 1320以啟動由H(e)NB ID識別的設備的的補救(8f_1)。它還可以包括失敗的模組的列表。根據失敗的功能性的列表和設備特定的配置資料表，H(e)MS 1320決定需要的韌體或者軟體更新。如果支援補救，則PVE 1315可以發送指示給H(e)NB 1305來為H(e)MS 1320發起的補救做準備(8f_2)。根據PVE 1315的回應，SeGW 1310會限制存取並將該結果通知給H(e)NB 1305(9f)。系統以FBC模式重新啟動以啟動設備發起的補救(10)。該步驟是可選的，因為重新啟動可以由H(e)MS 1320使用針對補救的TR069協定來處理。

這裏描述的是SAV的H(e)MS和PVE發現過程。H(e)NB可以被採用工廠的默認設置、包括PVE的IP位址、H(e)MS和OAM來進行配置。他們也可以由H(e)MS使用TR069協議通過如第9圖所示的TR069協定支援的設置參數(SetParameter)和獲取參數(GetParameter)RPC方法來配置。注意，該過程也可以被用來改變PVE的位址。也可以定義與ManagementServer.URL參數類似的其他參數(PlatformValidationServer.URL(平台確認伺服器.URL))以在H(e)NB上保持PVE URL。類似地，PlatformValidationServer.URL的工廠設置可以在製造的時候預先配置並之後被TR069更新。

這裏描述的是SAV的完整性方法和過程。在SAV中，設備完整性校驗可在本地進行。完整性校驗的結果可以通過失敗的功能性的列表的形式傳給PVE。因此例如本文段落[0038]-[0040]中描述的任何完整性校驗方法都可以使用。完整性校驗不是由網路實體進行。因此，可以留給製造商去決定合適的用於確認的完整性方法。然而，最低的安全需求可以被標準化，例如‘完整性方法必須提供等於或優於SHA-1的安全性。

這裏描述的是SAV中可用於TRV證書管理的機制。首先描述支援SAV的介面和訊息。PVE-SeGW介面可以使用點對點協定(PPP)。PPP可以提供對鑑定、加密和壓縮的支援。可替換地，傳輸層安全性/安全插口層(TLS/SSL)也可以使用。

有多個訊息可在PVE-SeGW介面上發送。例如，H(e)NB_Integrity_Information(H(e)NB_完整性_資訊)訊息可以包含失敗的功能性的列表，該列表是由H(e)NB通過IKEv2 NOTIFY(IKEv2通知)訊息發送給SeGW並由SeGW提取的。表7給出了一個該訊息的內容的實例。

H(e)NB_Integrity_Information訊息的回應是表8所示的H(e)NB_Validation_Result(H(e)NB_確認_結果)訊息。

PVE-H(e)MS介面也可以是基於PPP的，因為他們都是網路實體。可替換地，也可以使用TLS/SSL。在一個實例中，PVE和H(e)MS可以是一個實體。表9示出了一個該介面上的訊息的實例。

可替換地，PVE可以只發送失敗的功能性的列表(或者可選地，也發送所有通過完整性校驗的功能性的列表或者所有沒有通過完整性校驗的功能性的列表)，並且H(e)MS自己決定採取哪個行動。如表10所示。H(e)MS可以採取下述行動：立即補救、調度補救以及需要管理員干涉。

這裏描述了關於SAV的H(e)NB架構和功能性。H(e)NB架構可以包括外部的TrE完整性校驗者。H(e)NB的TrE可以將元件的完整性驗證任務委託給可以是被應用的硬體和/或軟體的外部實體，該元件的完整性驗證的任務是TrE的責任。這種情況在TrE不夠快或者沒有足夠的資源來進行設備完整性校驗之時可以使用。這種情況下，TrE驗證將會執行設備完整性確認任務的硬體和/或軟體實體的完整性和可靠性。成功確認之後，TrE允許外部完整性校驗者來執行該任務並將結果和測量資料報告給TrE。

H(e)NB實體可以有一個本地時間伺服器來為各種事件、報告和與網路的通信提供時間標記。這樣一個時間伺服器可以使用網路時間協定(NTP)來同步時間。該時間伺服器碼和NTP碼也應在它們被TrE或者外部TrE完整性校驗者執行之前進行完整性確認。

H(e)NB架構也可以將確認和鑑定結合起來。除了在AuV情況下用於確認和鑑定的結合的機制之外，確認和鑑定之間的結合可以由IKEv2會話提供，即，只在完整性校驗通過之後才發佈敏感密鑰和鑑定功能性。鑑定證書和SAV中本地確認的結果可以用IKEv2 IKE_AUTH_REQ訊息進行發送。SeGW濾出失敗模組的列表並將其轉發給PVE。如果該訊息中不包括這樣的列表，它則將該資訊中轉給PVE。PVE決定將來的行動，並將該結果指示給SeGW，在某些情況下指示給H(w)MS。

在另一個替換結合方法中，H(e)NB預先裝備了密鑰對，密鑰對中私有部分安全地儲存在H(e)NB的TrE內，而公共(public)部分對H(e)NB可用。H(e)NB的製造商可以產生該密鑰對並相應地提供私有和公共密鑰。為了通過加密方法建立確認和鑑定的結合，H(e)NB用來自證書的公共密鑰來加密其接收自AAA伺服器的(其中，AAA伺服器請求H(e)NB計算基於秘密的計算的鑑定材料並將它發回AAA伺服器)訊息(例如IKE_AUTH回應訊息)，並將加密的資料轉發給TrE。TrE然後解密該資料並計算該基於秘密的鑑定材料(例如，在使用了對稱鑑定的情況下的EAP-AKA RES參數，或者在使用了基於證書的鑑定的情況下的基於私有密鑰的使用的AUTH參數)，需要這些材料向AAA確認H(e)NB的標識的可靠性。

在一個替換結合方法中，密鑰和其他TrE的敏感計算能力對這些應用是不可存取的，除非H(e)NB的TrE知道了本地完整性校驗成功的結果，密鑰和其他TrE 的敏感計算能力由基於IKEv2的H(e)NB的設備鑑定應用來使用。

這裏描述了儲存在H(e)NB和PVE中的策略規範。H(e)NB設備配置檔描述了儲存在H(e)NB中的策略，它描述了諸如功能性ID、元件ID和模組ID等屬性，這些將在本文詳細描述。設備配置表在出廠時被初始化。該資訊的初始化過程和隨後的AuV更新在這裏描述並可應用於SAV的情況。

PVE策略配置檔可以包括失敗的功能性與SeGW行動、H(e)NB行動以及H(e)MS行動之間的映射。根據失敗的功能性的列表，PVE可以決定H(e)NB、SeGW和H(e)MS將會採取的行動。表11定義了這些行動。

這裏描述的是SAV中支持補救的方法。為了支持補救，H(e)NB與H(e)MS相互配合。該連接可以通過SeGW或者使用TLS/SSL直接通過網路。如果在安全啟動過程中，設備完整性校驗針對步驟1或步驟2編碼而失敗，則執行FBC並嘗試補救，其中步驟1或步驟2編碼是由製造商預先設計好的並包含了鑑定和與SeGW通信的必須的編碼以及TrE的編碼。

第14圖示出了包含了H(e)NB 1405、H(e)MS 1410和FTP伺服器1415的SAV補救的示例性流程圖1400。如果設備完整性校驗失敗並在RoT使用FBC啟動之後(0)，H(e)NB 1405與預先設計的H(e)MS伺服器1410建立連接(例如，通過使用TCP連接)(1)。然後執行SSL初始化和/或之後建立TLS(2)。H(e)NB 1405然後與H(e)MS 1410一起調用RPC方法通知(例如，遇險信號)(3)。該遇險信號可以包括設備ID(Device ID)、事件(Event)、最大包絡(MaxEnvelopes)以及當前時間(CurrentTime)。

設備ID(Device ID)是一個結構，該結構可以包含製造商名稱；設備製造商的組織唯一識別字(OUI)；產品分類(ProductClass)，可用於指示使用序列號的產品的分類，或可用於為了讓序列號(SerialNumber)屬性被用於指示TrE ID或H(e)NB ID而指示設備的序列號；以及序列號欄位，可用於發送特定設備的序列號或者用於發送TrE ID或H(e)NB ID。

事件(Event)欄位可以包含用於引起執行RPC方法通知的事件代碼。為了使TR069適應SAV補救，可能需要定義新的事件代碼(X_HeNB_FBC調用)來指示設備完整性校驗已經失敗以及FBC已經被調用以發送該遇險信號。最大包絡(MaxEnvelopes)值設為1。該值可以被忽略但仍設為1。當前時間(CurrentTime)欄位被設為H(e)NB 1405知道的當前日期和時間。

通知RPC方法向H(e)MS指示了設備完整性校驗已經失敗並且正在為發起韌體更新進行連接。然後H(e)MS調用RPC方法上傳(Upload)來指示H(e)NB上傳失敗的功能性的列表和製造商特定的錯誤碼列表(4)。這些錯誤碼可能涉及與完整性校驗已經失敗的元件一致的軟體模組或者可能包含特定於除錯的錯誤碼。提供了檔必須被上傳到的FTP伺服器1415的URL。注意，FTP伺服器1415可以由製造商維護。FTP伺服器1415可以是由製造商提供的補救伺服器。

H(e)MS 1410通過發送訊息Prepare_For_Upload(準備_上傳)來指示FTP伺服器1415準備上傳失敗的功能性的列表(5)。H(e)NB 1405然後調用HTTP/HTTPS/FTPS過程來上傳包含了失敗的功能性的列表的檔(6)。接收到該檔之後，當H(e)MS收集上傳的檔時，FTP伺服器1415或H(e)MS 1410評估需要的補丁或者韌體/軟體更新來解決問題(6a)。如果該包含了失敗的功能性的列表的檔被上傳到FTP伺服器1415，在評估完所需的補丁之後，FTP伺服器1415發送Download_Package_Ready(下載_包_就緒)訊息給H(e)MS(7)。如果H(e)MS已經收集了上傳的檔，則不需要該訊息。可替換地，如果H(e)MS 1410的功能性和FTP伺服器1415合併起來，則也不需要該訊息。

可替換地，該資訊可以直接從PVE處接收，並且不需要步驟1至5。

H(e)MS 1415然後調用RPC方法下載(Download)並提供韌體或者軟體位置的URL和設備配置資料表(8)。下述參數值可以被設置。CommandKey(公共密鑰)參數是可能會被H(e)NB 1405用來指示特定下載的字串，並且可以是任何字串。它被用來使下載和回應發生關聯。FileType參數可以針對韌體影像而被設置為“1 Firmware Upgrade Image”以及針對設備配置資料表被設置為“X_<OUI>_data_sheet”。URL參數是下載文件的URL。HTTP和HTTPS必須被支持。針對下載也推薦支持FTPS。Username參數可以被H(e)NB 1405用來鑑定FTP 伺服器1415。Password參數可以被H(e)NB 1405用來鑑定FTP伺服器1415。FileSize參數是要下載的文件的大小。還可以根據TR069協定需求設置其他參數。

H(e)NB 1405連接到FTP伺服器1415並下載韌體或者軟體影像和設備配置資料表(9)。一旦成功完整下載，可以發送一個具有值為0(指示成功)的狀態參數的DownloadResponse或者一個下載請求的錯誤回應(指示失敗)(10)。本文描述的替換過程也可接著用於指示成功或者失敗的下載。

在成功的DownloadResponse之後，H(e)MS 1415則調用H(e)NB 1405中的重新啟動過程(11)。H(e)NB 1405中的RPC處理者重置本地遇險標誌並正常啟動以執行上面指示的本地完整性校驗過程(11a)。簽名的包格式可以包含重新啟動命令，該命令用於指示H(e)NB 1405在韌體或軟體更新之後重新啟動。

可選擇地，可以從H(e)NB調用一個傳輸完成(TransferComplete)RPC方法來指示H(e)MS韌體/軟體更新過程已經成功完成(12)。注意，可替換地，SeGW可以發送訊息給H(e)MS以指示設備已經成功啟動，這會被H(e)MS解釋為韌體或軟體成功更新完成的訊息。第15圖示出了通過PVE進行SAV補救的實施例的流程圖1500。該過程包括H(e)NB 1505、SeGW 1510、PVE 1515、H(e)MS 1520和FTP伺服器1525。在安全啟動過程中，如果步驟1和步驟2編碼通過了完整性校驗並且被載入並成功進行了鑑定，則H(e)NB 1505可以與SeGW 1510進行通信，通過IKEv2訊息發送本地完整性校驗的結果(1)。H(e)NB 1505通過如第16圖所示的IKEv2 NOTIFY訊息1600發送失敗的功能性的列表和製造商特定的錯誤碼列表給SeGW 1510。

SeGW 1510然後可以通過H(e)NB_Integrity_Information訊息來發送本地完整性校驗的結果，該訊息可以包含失敗的功能性的列表和/或製造商特定的錯誤碼列表(2)。根據接收到的資訊，PVE 1515可以用H(e)NB_Validation_Result訊息來回應SeGW 1510，該訊息可以包含SeGW行動和H(e)NB行動(3)。SeGW 1510可以將H(e)NB行動轉發給H(e)NB1505(5)。H(e)NB可以相應地做準備並為本地補救做準備或者不採取行動。

根據接收到的資訊，PVE也可以發送H(e)NB_Validation_Result給H(e)MS 1520，該訊息可以包含失敗的功能性的列表、製造商特定的錯誤碼列表、H(e)MS行動和H(e)NB ID(4)。根據由PVE 1515發送給H(e)MS 1520的行動，H(e)MS 1520可以調度補救更新或者立即更新。在這兩種情況中，H(e)MS 1520將該列表發送給製造商特定的補救FTP伺服器。

H(e)MS 1520可以將H(e)NB_Validation_Result訊息轉發給FTP伺服器1525，該訊息可以包含失敗的功能性列表、H(e)NB ID及製造商特定的錯誤碼列表(4a)。FTP伺服器1525可以評估韌體/軟體下載檔並準備下載包(4b)。FTP伺服器1525向H(e)MS 1520發送Download_Package_Ready訊息。如果H(e)MS 1520收集上傳的檔，則由此可以不需要該訊息。可替換地，如果H(e)MS 1520和FTP伺服器1525合併起來，則該訊息也不需要發送。

H(e)MS 1520然後調用RPC方法下載並提供韌體/軟體位置的URL和設備配置資料表(7)。下述參數值可以被設置。CommandKey參數是可能會被H(e)NB 1505用來指示特定下載的字串，也可以是任何使下載和回應發生關聯的字串。FileType參數可以針對韌體影像被設置為“1 Firmware Upgrade Image”以及針對設備配置資料表被設置為“X_<OUI>_data_sheet”。URL是下載文件的URL。

HTTP和HTTPS必須得到支持。針對下載也推薦支持FTPS。Username參數可以被H(e)NB 1505用來鑑定檔伺服器。Password參數可以被H(e)NB 1505用來鑑定檔伺服器。FileSize參數是要下載的文件的大小。還可以根據TR069協定需求設置其他參數。

H(e)NB 1505連接到FTP伺服器1525並下載韌體/軟體影像和設備配置資料表(8)。一旦成功完整下載，一個具有值為0(指示成功)的狀態參數(argument)的DownloadResponse或者一個下載請求的錯誤回應(指示失敗)被發送給H(e)MS 1520(9)。TR069中描述的替換過程也可接著用於指示成功或者失敗的下載。

在成功的DownloadResponse之後，H(e)MS 1520則調用H(e)NB 1505中的重新啟動過程(10)。H(e)NB 1505中的RPC處理者重置本地遇險標誌並正常啟動以執行上面指示的本地完整性校驗過程(10a)。可替換地，簽名的包格式可以包含重新啟動命令，該命令用於指示H(e)NB 1505在韌體或軟體更新之後重新啟動。在韌體/軟體更新成功完成之後，可以向SeGW 1510發送傳輸完成訊息(11)。可替換地，傳輸完成(TransferComplete)RPC方法可以由H(e)NB 15.05調用以向H(e)MS 1520指示韌體/軟體更新已經成功完成。在另一個實例中，SeGW 1510可以發送訊息給H(e)MS 1520以指示設備已經成功啟動，這會被H(e)MS 1520解釋成一個成功的韌體/軟體更新完成訊息。

這裏描述的是在平台確認和管理(PVM)架構中使用SAV的架構和方法。PVM提供了一種系統方法來確認和管理設備，當他們首先嘗試附著到通信網路上以及隨後的監視設備的完整性、通過來自可信的計算的安全技術信賴部分。PVM提供：1)在允許網路連接之前確認設備；2)通過無線電(OtA)管理設備配置；3)通過在元件載入/開始上校驗RIM的安全啟動；以及4)配置改變時在設備上安裝新的RIM-RIM攝取。

PVM可以使用下述術語。術語“驗證(verification)”可用於安全建立期間設備元件的內部驗證，而術語“確認(validation)”用於由外部實體進行的整個校驗過程。這樣，就可以避免介紹“內部”相對“外部”確認了。其中確認用於通常意義上的加密校驗或者資料匹配，這是明確需要注意的，這樣才不會引起混淆。

PVM使用SeGW、PVE和DMS中的至少一個。由於設備中的TrE執行設備內部的確認關鍵任務，因此通常TrE與其他實體進行通信。而該通信需要的設備的其他元件例如網路介面，不是TrE組成部分中必須的，可以由TrE來評估這些元件的完整性以確保端到端的安全。

職責的嚴格劃分需要每一個實體限制於它的核心任務。例如，SeGW在(不)可信的設備與MNO的CN之間建立安全介面。它作為關卡和網路存取控制以及MNO的CN的強制實例。它也進行所有安全相關的(作為這樣一個關卡必須的)功能，包括鑑定、對與設備的通信進行加密/解密、安全聯盟和對話建立。SeGW可被用於作為在MNO的CN與外界之間建立邊界的網路實體的一個實例，所述外界例如外部設備。使用PVM方法進行設備確認也可能不需要SeGW。這樣做可能包括使用安全連接例如傳輸層安全性(TLS)直接將設備連接到DMS。

至於PVE，它作為CN中的確認實體並執行完整性確認。它接收完整性確認資料並檢驗報告的值是否已知並是好的。它向CN中其他實體發佈有關設備完整性的報告。

至於DMS，它作為設備元件管理的中心實體，這些元件包括軟體更新、配置改變、OTA管理和失敗模式補救。DMS在根據平台確認執行該功能方面，與H(e)MS的增強版本類似。

除了上述實體外，PVM還包括RIM管理器(RIMman)。RIMman執行下述任務，包括管理和提供用於確認中的比較的參考值。它也管理證書，尤其，攝取外來的RIM證書、驗證RIM證書、產生(運營商特定的)RIM證書以及通過例如撤回、時間限制和信任關係來校驗證書的有效性。也就是說，RIM管理器是唯一的實體，它被授權以管理確認資料庫(V_DB)。該V_DB和RIMman是受保護的CN元件。對V_DB的寫存取許可權僅限於RIMman，因此PVE不能向V_DB寫入。RIMman在安全方面具有特殊的重要性，因為它管理著PVM必須的(SHO-CN)外部信任關係。

PVM還包括進行管理和提供設備配置的配置策略管理器(CPman)。它也管理策略，尤其是，從例如可信的第三方(TTP)攝取外部配置和策略，並產生(運營商特定的)目標設備配置和策略。也就是說，CPman是被授權來管理配置策略資料庫C_DB的唯一的實體。CPman在安全方面具有特殊的重要性，因為它管理PVM必須的(SHO-CN)外部信任關係。

第17A圖和第17B圖示出了PVM的實體的最小組、它們的關係和介面的實例。也示出了其他實體，例如鑑定、鑑定&計費(AAA)伺服器和無線發射/接收單元(WTRU)和他們的介面。

第17A圖中的PVM架構或者系統1700包括具有TrE 1710的設備1705。WTRU 1712(或者使用者實體(UE))可以通過I-ue介面1714與設備1705進行通信。設備1705通過I-h介面1715與SeGW 1720進行通信。總的來說，設備1705和SeGW 1720之間的介面I-h 1715可能不受保護，並且可以使用特殊的測量來確保該通道的可靠性、完整性和可選的保密性。I-h 1715可以被用於建立設備1705與SeGW 1720以及CN之間的鏈路。例如，SeGW 1720可以通過介面I-aaa 1775與AAA伺服器通信。運營商可以建立適當的測量來確保該介面的安全。

I-pve介面1722可以被SeGW 1720用來在確認過程中與PVE 1724聯繫。PVE 1724可以使用I-pve介面1722將確認的結果用信號通知給SeGW 1720。I-dms介面1730可以用於設備配置相關的DMS 1735與SeGW 1720之間的通信。該I-pd介面1732可以被PVE 1724用來與DMS 1735進行通信，反之亦然。介面I-pd 1732可用於設備管理過程中，例如用於設備軟體更新和配置改變。

介面I-v 1726和I-d 1738可以分別被PVE 1724用於從V_DB 1740讀取RIM以及被DMS 1735用來從C_DB 1750讀取允許的配置。介面I-r 1728和I-c 1734可以被PVE 1724用來與RIMman 1760進行通信，例如在V_DB 1740中缺少RIM的情況下，並被DMS 1735用來與CPman 1770進行通信。RIMman 1760和CPman 1770可以分別使用介面I-rdb 1762和I-cdb 1772來讀、寫和管理資料庫V_DB 1740和配置策略資料庫C_DB 1750。

第17B圖示出了PVM 1782，其中設備1705可以直接與DMS 1735連接。當該設備是H(e)NB時，DMS 1735應該是如之前描述的H(e)MS。例如，對於其中設備1705不能與SeGW進行安全協定的回退模式。在這種情況下，DMS 1735可以作為通過介面I-dms_d 1784第一次聯繫設備1705的點，並通過介面I-pve 1786和I-pd 1788與PVE 1724通信來執行確認，或者至少得知哪些元件在安全建立過程中已經失敗了。DMS 1735可以根據該資訊為補救而行動。

如本文所述，PVM可以使用任何版本的確認。這裏描述的是與PVM一起工作的半自動確認(SAV)的一個實施例。我們將焦點放在半自動確認(SAV)的演進型確認方法上。SAV的這個解決方法的優點是進一步地使CN完全免受流氓(rogue)設備的影響。在SAV過程中，由SeGW有效地建立起一個隔離。設備對PVE和DMS沒有直接的威脅，因為它們只能接收限於它們的任務的資料並且只能通過與SeGW的安全連接，或者由SeGW建立。SAV中的確認過程不需要設備與CN中的任何實體之間的直接通信。只有在使用SAV成功確認之後，才允許連接到CN。這確保了只有被證明處於安全狀態的設備才能與CN中的實體進行通信。

第18A圖、第18B圖和第18C圖示出了一個使用PVM基礎結構的SAV確認方法實例的示意圖。該PVM基礎結構包括本文描述的實體，包括TrE 1805、SeGW 1807、PVE 1809、DMS 1811、V_DB 1813以及C_DB 1815。在相互鑑定(1820)之後，TrE 1805可以收集下列資料的部分或全部：設備資訊例如Dev_ID、製造商、設備能力(包括但不限於通信能力例如支援的資料速率、傳輸功率等級、信令特性和其他能力)、TrE能力和性質包括RoT；TrE_資訊包括ID、認證資訊、製造商、建立版本和可選的模型、樣式、序列號；確認資料包括1)設備的失敗的功能性的列表，和/或2)平台配置暫存器(PCR)值；確認結合例如通過PCR值的簽名或者失敗的設備功能性的列表；元件Clist的元件指示符(CInd)的有序列表以及可以包括元件的參數；以及時間標記(可信的或不可信的)(1822)。從TrE 1805到SeGW 1807的確認訊息/資料可以包含上述資料(1824)。

SeGW 1807應該將接收到的時間標記與本地時間進行校驗/比較來檢測變化(1826)。如果報告的時間標記與本地時間不匹配，則SeGW根據報告的時間標記的屬性而行動。如果設備的時間標記是可信的時間標記並且顯示了變化，則SeGW 1807應該觸發TrE的重新確認以及它的可信的時間源。在不可信的時間標記的情況下，SeGW 1807將它自己可信的時間標記加到該訊息上。如果該設備不能提供可信的時間標記，則SeGW 1807可以加入一個可信的時間標記作為防止重放(replay)攻擊之用。

一旦接收到該訊息，則SeGW 1807可以校驗是否出現來自TrE的簽名形式的確認結合(1828)。這確保了確認資料的可靠性。SeGW 1807然後建立PVM權杖(T_PVM)(1830)並在發送之前在該T-PVM上應用時間標記以確保時新性並阻止非同步訊息流(1832)。

SeGW 1807將該T_PVM轉發給PVE 1809(1834)，它們輪流查詢使用TrE-資訊的V_DB 1813(1836)。如果向PVE 1809返回了一個不值得信任的確定(1838)，PVE則對T_PVM應用時間標記(1840)並將它轉發給SeGW 1807(1842)。SeGW 1807發送設備鑑定的否定到TrE 1805(1844)。

如果向PVE 1809返回了一個值得信任的確定(1846)，則該PVE查詢使用Dev_ID的C_DB(1848)，它們輪流向PVE 1809返回配置策略(1850)。該PVE 1809評估該配置策略(1852)。

如果該PVE 1809確定該配置是不值得信任的(1854)，則PVE 1809修改T_PVM並應用時間標記 (1856)。該PVE 1809然後將該T_PVM轉發給SeGW 1807(1858)，它們輪流發送設備鑑定的否定到TrE 1805(1860)。

如果該PVE 1809確定該配置是值得信任的並允許該配置(1862)，則PVE 1809通過Clist或者來自V_DB 1813的C_List(C_列表)為所有實體恢復RIM(1864)。該PVE 1809重新計算來自RIM的正確的確認資料(1866)並將計算出的確認資料與報告的確認資料進行比較(1868)。在SAV的情況下，來自RIM的計算出的確認資料可以為失敗的功能性的‘空的列表’的形式。PVE 1809然後修改T_PVM並應用時間標記(1870)。PVE 1809然後將T_PVM轉發給SeGW 1807(1872)。SeGW 1807針對PVE確認結果檢查T_PVM(或者從T_PVM進行提取)(1874)。SeGW 1807向TrE 1805發送設備鑑定的否認或允許(1876)。如果PVE確認結果是否定的，則TrE 1805執行重新啟動並進行重新確認(1890)。

可選地，在PVE 1809將計算出的確認資料與報告的確認資料進行比較之後(1868)，PVE 1809可以發送一個失敗的元件的列表給DMS 1811(1878)。如果該失敗的元件的列表不為空，則DMS 1811可以確定可以應用軟體或韌體的更新(1880)，並且如果是這樣的話，準備好OTA更新(1882)。DMS 1811也確保用於更新的RIM在V_DB 1813中存在(1884)。該DMS 1811通過用於重新確認的指示向SeGW 1807發送T_PVM(1886)以及向TrE 1805發送重新確認觸發(1888)。TrE 1805執行重新啟動並進行重新確認(1890)。

這裏描述了關於第18A圖、第18B圖和第18C圖中的過程的具體情況。為了執行平台確認，TrE收集如下資料並將其傳達給SeGW：設備資訊例如Dev_ID、製造商、TrE能力和性質包括RoT；TrE_資訊包括ID、認證資訊、製造商、建立版本和可選的模型、樣式、序列號；完整性確認資料(IVD，一個IVD的實例可以是簽名的平台配置暫存器(PCR)值，另一個實例可以是簡單的元件或功能性的列表，這些元件或功能性的完整性被設備本地完整性校驗過程校驗過，並且進一步地被評估為沒有通過這樣的設備本地完整性檢驗；確認結合例如PCR值上的簽名；Clist-它是元件Clist的元件指示符(CInd)的有序列表並且可以包含元件的參數；該元件的列表將會服務於識別確認的RIM，例如，通過指向RIM證書，RIMcs。該元件的指示符的有序列表和它們的參數可以包含如下資料欄位的項：索引、元件_指示符CInd、組件_參數。CInd給出了元件的參考並且可以為URN格式(例如URN：//vendor.path.to/component/certificate))。可選地：時間標記(這可以是可信的時間標記，或者通常意義上不需要是可信的常態時間標記)。

在該設備的情況下，確認訊息還可以額外包括設備資訊，例如ID、認證資訊、製造商、模組、版本、樣式、序列號。TrE能力和性質包括RoT、設備的安全策略、在完整性校驗以及校驗之後元件載入的多步驟過程中的不同步驟通過完整性校驗的模組、HW建立版本號以及可選的SW建立版本號和完整性測量資料。

將RIM用於確認是一種用於SAV的較佳但可選的方法。它在這裏作為基本情況使用，其他選項背離了它。例如，存在沒有重新計算來自RIM的確認資料的確認，甚至還有可能完全沒有RIM而執行PVM。

如果確認訊息必定是通過其他而不是那些包括設備完整性的方法，例如通過安全通道的存在和使用，驗證結合可以是可選的。

SeGW可以將接收到的時間標記與本地時間進行校驗/比較以檢測變化。如果報告的時間標記與本地時間不匹配，則SeGW根據報告的時間標記的性質採取行動。如果該設備的時間標記是可信的時間標記並且顯示出變化，SeGW會觸發TrE的重新確認及它的可信的時間源。在不可信的時間標記的情況下，SeGW將它自己的時間標記加到訊息中。

TrE_info(TrE_資訊)可以是可選的。Dev_ID可以給出TrE_info的參考。由於不是所有的MNO都會知道所有的TrE，因此所有的TrE_info資料，可以由資料庫提供這樣一個映射，該資料庫可以由MNO查詢來獲得任何給定Dev_ID的TrE_info。TrE_info可以在TrE_certificate(TrE_證書)中。該TrE_certificate應被TrE的供應商或者TTP簽名，例如同族(german)BSI。

使用URN作為元件的指示符(CInd)是有利的，因為它同時允許元件的這個唯一標識和可以取得RIM或RIM證書的位置。

SeGW建立PVM權杖(T_PVM)，該T_PVM可用於作為輪詢權杖並且在通信中在實體之間傳遞。每一個實體在發送之前將一個時間標記放到該權杖上來確保時新性以及阻止非同步訊息流。該權杖上的時間標記可以被用於提供一種跟蹤權杖狀態的方法。該權杖在CN中的實體之間傳遞，甚至幾個來回，因此可以被實體跟蹤到。可選地，實體ID可以加入到該時間標記的資料鏈中。

T_PVM可以包含Dev_ID。如果該原始時間標記不存在或不可信，該T_PVM也可以包含由SeGW發佈的新的時間標記。否則該T_PVM可以包含來自確認訊息的原始時間標記。

時間標記可被用於避免重放攻擊。它們可以與亂數或者單調(monotonically)遞增的計數器合併或者甚至被他們替代。時間標記也可被用於評估確認資料的時新性。兩種目的的結合是有利的且可以由時間標記提供。在第一種變型中，對於通過DMS、T_PVM的後來的設備管理可以包含在DMS與TrE之間建立安全通道的通信秘密，例如TLS證書。

SeGW維護包含所有啟動的T_PVM的權杖資料庫T_DB。

SeGW從確認訊息中提取如下資料：確認資料、TrE_info和Clist。在將該資料與權杖T_PVM一起發送之前，SeGW在T_PVM上放置時間標記並將它轉發給PVE。SeGW可以校驗該確認訊息及其部件的格式以減輕來自錯誤形成的資料攻擊。否則，攻擊者會嘗試修改妥協的TrE的確認訊息中的資料，由此在PVE上的對該資料的純粹的檢查會導致系統錯誤或失敗。

PVE是決定設備有效性的實體。也就是，用策略系統的語言來說，它是一個策略決策點(PDP)。在嚴格的責任分離方法下，它是PVM系統中唯一的PDP。它依賴SeGW和DMS來實施策略，例如作為策略實施點(PEP)。用它通常的描述，PVM保持著對策略是如何產生的和它們在哪里儲存/管理的問題的不可知，例如PVE從哪里得到該策略。在下面描述的一些更具體的變型和次要的方法中(尤其參數的確認和最小的確認)，給出了策略條件和行動的一些實例。通常，確認策略的決定可以不僅根據單個元件的有效性也要根據Clist中包含的其他資料。尤其是，可以評估允許的參數(範圍)和載入順序(Clist是有序的)。

失敗條件有一些基本的等級，可以發生在由PVE執行的確認過程中。例如，失敗條件F1指示一種“TrE 無效”場景。通過它的經過鑑定的Dev_ID和傳遞的TrE_info，PVE識別設備和/或它的TrE哪一個不值得信任。注意：能被用於確定TrE是否無效的資訊可以在SAV確認訊息上進行攜帶，或可以從其他訊息或其他方法中推出。在它基本的形式中，SAV確認訊息的存在可以隱式地指示TrE本身必須是有效的。怎樣檢測F1的具體描述在同時提交的申請號為No.______，題為“無線設備的平台確認和管理”的美國專利申請中，它作為參考加入本文，就如同本文具體描述一樣。

另一個實例是失敗條件F2，它指示“IVD驗證失敗”的三種場景。場景F2a指示完整性測量/驗證資料不匹配。它指示設備的安全啟動過程的失敗，和/或錯誤的存在和/或過期的RIM和/或設備的RIM證書，然後啟動無效的元件。場景F2b指示RIM遺失，也就是，元件的RIM遺失並且需要從其他地方取回。場景F2c指示過期的RIM證書。

失敗條件F3指示“Clist策略失敗”的兩種場景。對場景F3a，單個元件是有效的，但該配置使一個策略失敗，例如在載入順序上或者非期望的元件或參數。場景F3b指示配置未知，這樣Clist的‘已知的好值’不可用。這裏描述的是檢測和處理失敗條件等級F2的一種方法。對於失敗條件F2，PVE針對來自接收到的Clist的所有組件從V_DB取回RIM。確認資料庫V_DB只儲存認證過的RIM。相關的RIM證書必須安全地存放在V_DB中。

如果IVD是“與本地完整性校驗失敗的設備的元件相應的設備元件”的一個簡單列表的形式，就如本文描述的狹義的SAV過程，則IVD_ref會簡單的是一個空的列表的形式。也就是，在這種情況下，IVD_ref應僅僅是預期的失敗的功能性的列表，如果每一個元件都預期通過了設備本地完整性校驗，則該列表應該是一個空表。

如果IVD_ref與接收到的IVD不匹配，則設備上的安全啟動過程已經被妥協或者錯誤的RIM被儲存到該設備中，以及無效的元件因此在該安全啟動過程中被載入。根據該F2a策略，一旦檢測到F2a失敗，可以應用一些選項。在一個選項中，拒絕。PVE用信號通知SeGW確認的結果。SeGW然後可以拒絕網路存取或者將該設備放入隔離的網路中。另一個選項被更新。在接收到指示驗證資料失敗的確認結果(T_PVM)之後，DMS開始一個管理過程來替代確認失敗的元件。這樣一個補救過程的具體描述在同時提交的申請號為No._____，題為“無線設備的平台確認和管理”的美國專利申請中，它作為參考加入本文，就如本文詳細描述一樣。

如果沒有策略失敗條件得到滿足，則該設備是有效的。PVE將其用信號通知給SeGW，然後它允許連接到CN。

對失敗條件F2b，其中RIM遺失了，這個發生可能是因為RIM可以在V_DB中遺失，或者它可以在該設備中遺失(因此，在這種情況下，該設備不能進行設備本地完整性校驗過程)。怎樣檢測F2的具體描述在同時提交的申請號為No._____，題為“無線設備的平台確認和管理”的美國專利申請中，它作為參考加入本文，就如本文詳細描述一樣。

這裏描述的是檢測和處理失敗條件等級F3的方法。如果單個元件是有效的但元件的配置使一個策略失敗(例如載入順序不匹配)，或者如果該配置未知，即Clist的‘已知的好值’不可用，該F3失敗條件發生。這樣一個失敗條件怎樣發生和這樣一個失敗條件能怎樣被處理的詳細描述在同時提交的申請號為No._____，題為“無線設備的平台確認和管理”的美國專利申請中討論，它作為參考加入本文，就如本文詳細描述一樣。

第19圖示出了一個長期演進(LTE)無線通信系統/存取網路1900，包括演進型全球陸地無線電存取網路(E-UTRAN)1905，它可以與H(e)NB一起使用。E-UTRAN 1905包括一個WTRU 1910和若干演進型節點B(eNB 1920)。WTRU 1910與eNB 1920進行通信。eNB 1920使用X2介面相互連接。每一個eNB 1920通過S1介面與移動性管理實體(MME)/服務閘道(S-GW)1930相連。儘管第19圖中只示出了一個WTRU 1910和三個eNB 1920，但應該很明顯，任何無線和有線設備的組合都可以包含在該無線通信系統存取網路100中。

第20圖是包括WTRU 1910、eNB 1920和MME/S-GW 1930的LTE無線通信系統2000的示例性方塊圖。如第20圖所示，WTRU 1910、eNB 1920和MME/S-GW 1930被配置來執行使用自動和半自動確認的H(e)NB完整性驗證和確認的方法。

除了可以在典型WTRU中找到的元件外，WTRU 1910還包括具有可選鏈結的記憶體2022的處理器2016、至少一個收發信機2014、可選的電池2020和天線2018。該處理器2016被配置來執行使用自動和半自動確認的H(e)NB完整性驗證和確認的方法。該收發信機2014與處理器2016和天線2018進行通信以方便無線通信的傳送和接收。如果WTRU 1910中使用了電池2020，該電池2020給收發信機2014和處理器2016提供電能。

除了可以在典型eNB(包括H(e)NB)中找到的元件外，eNB 1920還包括具有可選鏈結的記憶體2015的處理器2017、收發信機2019、天線2021。該處理器2017被配置來執行使用自動和半自動確認的H(e)NB完整性驗證和確認的方法。該收發信機2019與處理器2017和天線2021進行通信以方便無線通信的傳送和接收。該eNB 1920連接到移動性管理實體/服務閘道(MME/S-GW)1930，MME/S-GW包括具有可選鏈結的記憶體2034的處理器2033。

SeGW和PVE，儘管在第19圖和第20圖中沒有示出，除了在典型的SeGW和PVE中可以找到的元件外，還包括具有可選鏈結的記憶體的處理器、收發信機、天線和通信埠。該處理器被配置來執行平台確認和管理函數以完成PVM方法。該收發信機和通信埠與處理器和天線根據需要進行通信，以方便通信的傳送和接收。

實施例

1．一種用於對家庭演進型節點B(H(e)NB)執行完整性驗證的方法，該方法包括在元件載入之前測量元件的完整性度量。

2．根據實施例1所述的方法，該方法還包括鑑定可信的參考值(TRV)。

3．根據前述任一實施例所述的方法，該方法還包括將測量的完整性度量與TRV進行比較。

4．根據前述任一實施例所述的方法，該方法還包括根據完整性驗證結果而採用常態碼或者回退碼中的一個來啟動H(e)NB。

5．根據前述任一實施例所述的方法，該方法還包括提供軟體模組和關聯屬性的列表，該列表包括至少一個參考完整性度量以及H(e)NB和平台確認實體(PVE)中的至少一個的嚴重性。

6．根據前述任一實施例所述的方法，其中設備配置資料表包含所述軟體模組和關聯屬性的列表，並且該設備配置資料表被提供給所述H(e)NB和平台確認實體(PVE)中的至少一個。

7．根據前述任一實施例所述的方法，其中所述關聯屬性提供了提供了元件相關的軟體模組與功能性之間的映射。

8．根據前述任一實施例所述的方法，其中所述設備配置資料表及所述軟體模組和關聯屬性的列表中的至少一個被儲存在所述H(e)NB和平台確認實體(PVE)中的至少一個內。

9．根據前述任一實施例所述的方法，該方法還包括基於所述PVE能確定哪個行動而發送至少包含模組識別字的完整性校驗失敗訊息。

10．根據前述任一實施例所述的方法，該方法還包括根據完整性驗證失敗的嚴重性等級來執行預先確定的行動。

11．根據前述任一實施例所述的方法，其中所述預先確定的行動包括下列中的至少一個：發送遇險訊息、發起碼更新、發起補救、以及報告失敗的功能性的列表。

12．根據前述任一實施例所述的方法，其中所述軟體模組和關聯屬性的列表包括下列中的至少一個：元件特定的資訊元素、模組特定的資訊元素和功能元素。

13．根據前述任一實施例所述的方法，其中所述元件特定的資訊元素包括下列中的至少一個：元件描述、元件標識(ID)和可信的參考值(TRV)。

14．根據前述任一實施例所述的方法，其中所述模組特定的資訊元素包括下列中的至少一個：模組描述、模組標識(ID)、功能描述、功能ID、組件ID、發佈版本和嚴重性。

15．根據前述任一實施例所述的方法，其中所述模組在完整性驗證期間至少被校驗一次。

16．根據前述任一實施例所述的方法，其中所述模組只在一個元件中出現。

17．根據前述任一實施例所述的方法，其中所述模組在兩個功能之間被共用。

18．根據前述任一實施例所述的方法，其中每一個模組都有關聯的功能性。

19．根據前述任一實施例所述的方法，其中一組模組與同一元件關聯、共用同一元件識別字(ID)並且與所述同一元件共同地進行完整性驗證。

20．根據前述任一實施例所述的方法，其中具有一個元件識別字(ID)的模組被以不同的功能性識別字(ID)進行分類。

21．根據前述任一實施例所述的方法，其中模組是基於功能性和完整性校驗量子進行分類的。

22．根據前述任一實施例所述的方法，其中具有同一元件識別字的模組具有一個可信的參考值(TRV)，並且在該可信的參考值失敗的條件下，具有失敗的元件識別字的所有模組都被用來確定失敗的功能性的列表。

23．一種用於對家庭演進型節點B(H(e)NB)執行確認的方法，該方法包括由於設備完整性校驗失敗而以回退碼來啟動所述H(e)NB。

24．根據實施例23所述的方法，該方法還包括發送遇險訊息。

25．根據實施例23-24中任一實施例所述的方法，該方法還包括接收用於取回補救資訊的下行鏈路訊息。

26．根據實施例23-25中任一實施例所述的方法，該方法還包括回應於所述下行鏈路訊息而下載所述補救資訊。

27．根據實施例23-26中任一實施例所述的方法，該方法還包括基於安裝的補救資訊而重新啟動所述H(e)NB。

28．根據實施例23-27中任一實施例所述的方法，該方法還包括上傳失敗資訊以允許準備所述補救資訊。

29．根據實施例23-28中任一實施例所述的方法，其中所述遇險訊息包括下列中的至少一個：製造商標識、可信的環境標識、H(e)NB標識和失敗碼。

30．根據實施例23-29中任一實施例所述的方法，其中嚴重性測量指明了設備完整性校驗失敗的影響。

31．根據實施例23-30中任一實施例所述的方法，其中設備完整性校驗在本地執行。

32．根據實施例23-31中任一實施例所述的方法，其中所述失敗資訊被發送給H(e)NB管理系統(H(e)MS)或者平台確認實體(PVE)中的一個。

33．根據實施例23-32中任一實施例所述的方法，其中所述H(e)NB使用安全插口層/傳輸層安全性(SSL/TLS)來發送所述遇險訊息。

34．根據實施例23-33中任一實施例所述的方法，其中所述H(e)NB是以系統預設H(e)MS統一資源定位器(URL)來配置的。

35．根據實施例23-34中任一實施例所述的方法，其中設備配置資料表在設備的安全記憶體中被維護並被授權方存取。

36．根據實施例23-35中任一實施例所述的方法，其中一旦設備配置資料表期滿，所述H(e)NB就發起更新過程以從補救伺服器上拉取資料。

37．根據實施例23-36中任一實施例所述的方法，其中所述H(e)NB執行預先指定的元件的設備完整性校驗。

38．根據實施例23-37中任一實施例所述的方法，該方法還包括從所述PVE接收H(e)NB行動。

39．一種用於對家庭演進型節點B(H(e)NB)執行確認的方法，該方法包括建立網際網路密鑰交換(IKE)安全聯盟。

40．根據實施例39所述的方法，該方法還包括以IKE_AUTH 請求來發送證書以對設備完整性校驗結果進行相互鑑定和指示。

41．根據實施例39-40中任一實施例所述的方法，該方法還包括接收對鑑定和設備完整性確認結果的指示。

42．根據實施例39-41中任一實施例所述的方法，該方法還包括基於對設備完整性校驗結果的評估而接收行動。

43．根據實施例39-42中任一實施例所述的方法，其中所述設備完整性校驗結果包括失敗的功能性的列表。

44．根據實施例39-43中任一實施例所述的方法，其中接收到的行動調用補救。

45．根據實施例39-44中任一實施例所述的方法，其中所述H(e)NB中的完整性校驗結果被隔離，被完全存取、被部分存取或者為補救而被人為干預。

46．根據實施例39-45中任一實施例所述的方法，該方法還包括回應於指示補救的行動而發送遇險訊息。

47．根據實施例39-46中任一實施例所述的方法，該方法還包括接收用於取回補救資訊的下行鏈路訊息。

48．根據實施例39-47中任一實施例所述的方法，該方法還包括回應於所述下行鏈路訊息而下載所述補救資訊。

49．根據實施例39-48中任一實施例所述的方法，該方法還包括基於安裝的補救資訊而重新啟動所述H(e)NB。

50．根據實施例39-49中任一實施例所述的方法，該方法還包括上傳失敗資訊以允許準備所述補救資訊。

51．根據實施例39-50中任一實施例所述的方法，其中失敗資訊包括失敗的功能性的列表。

52．根據實施例39-51中任一實施例所述的方法，其中所述失敗資訊被發送到H(e)NB管理系統(H(e)MS)或平台確認實體(PVE)中的一個。

53．根據實施例39-52中任一實施例所述的方法，其中所述失敗資訊包括校驗後的功能性的列表。

54．根據實施例39-53中任一實施例所述的方法，其中所述失敗資訊包括未校驗的功能性的列表。

55．根據實施例39-54中任一實施例所述的方法，其中確認和鑑定的結合由IKE會話提供。

56．根據實施例39-51中任一實施例所述的方法，其中確認和鑑定的結合由在設備完整性校驗成功的基礎上進行的鑑定過程提供。

57．一種用於結合設備確認的方法，該方法包括將可信的環境(TrE)結合到鑑定過程中。

58．根據實施例57所述的方法，其中所述鑑定過程是用於UMTS鑑定和密鑰協商的可擴展的鑑定協議方法(EAP-AKA)過程。

59．根據實施例57-58中任一實施例所述的方法，其中所述過程確認AKA憑證。

60．根據實施例57-59中任一實施例所述的方法，其中所述AKA憑證包含在TrE中。

61．根據實施例57-60中任一實施例所述的方法，該方法還包括將確認的設備和基於EAP-AKA的鑑定進行結合。

62．根據實施例57-61中任一實施例所述的方法，其中所述EAP-AKA鑑定包括將所述TrE擁有所述AKA憑證與基於EAP-AKA的鑑定過程進行結合。

63．根據實施例57-62中任一實施例所述的方法，該方法還包括將TrE擁有AKA憑證與增強型家庭節點B(HeNB)進行邏輯結合。

64．根據實施例57-63中任一實施例所述的方法，其中所述設備平台的完整性被確認。

65．根據實施例57-64中任一實施例所述的方法，該方法還包括將TrE擁有AKA憑證與HeNB進行實體結合。

66．根據實施例57-65中任一實施例所述的方法，其中硬體和軟體的實際的完整性確認是由安全內嵌在HeNB內的硬體安全元件執行的。

67．根據實施例57-66中任一實施例所述的方法，其中EAP-AKA鑑定適當的憑證和儲存在實體上密切關聯的TrE內的相關應用被配置成確認可移除的硬體元件與主機設備的結合。

68．根據實施例57-67中任一實施例所述的方法，其中所述TrE擁有AKA憑證和HeNB進一步密切相關。

69．根據實施例57-68中任一實施例所述的方法，該方法還包括所述HeNB加密計算用於設備鑑定的AKA憑證需要的資料，由此只有TrE能解密所述資料。

70．根據實施例57-69中任一實施例所述的方法，該方法還包括所述TrE安全地儲存解密所述HeNB加密資料所需要的密鑰。

71．根據實施例57-70中任一實施例所述的方法，該方法還包括將在公共安全協定的同一會話中設備確認和設備鑑定有關的資訊結合起來以獲得進一步的結合。

72．根據實施例57-71中任一實施例所述的方法，其中所述公共安全協議是網際網路密鑰交換版本2(IKEv2)。

73．根據實施例57-72中任一實施例所述的方法，其中所述設備確認包括HeNB與網路實體之間的交互和訊息交換。

74．根據實施例57-73中任一實施例所述的方法，其中所述HeNB包括TrE。

75．根據實施例57-74中任一實施例所述的方法，該方法還包括網路實體執行HeNB的確認。

76．根據實施例57-75中任一實施例所述的方法，該方法還包括安全閘道在所述HeNB與執行確認的網路實體之間傳達信令。

77．根據實施例57-76中任一實施例所述的方法，該方法還包括將設備確認與基於證書的鑑定進行結合。

78．根據實施例57-77中任一實施例所述的方法，其中所述結合包括將HeNB的TrE與基於證書的設備鑑定過程進行實體結合。

79．根據實施例57-78中任一實施例所述的方法，其中所述結合包括將HeNB的TrE與基於證書的設備鑑定過程進行邏輯結合。

80．根據實施例57-79中任一實施例所述的方法，其中所述TrE擁有證書憑證並且HeNB進一步密切相關。

81．根據實施例57-80中任一實施例所述的方法，該方法還包括HeNB使用加密密鑰來加密計算用於設備鑑定的證書憑證所需要的資料；並且所述TrE使用TrE安全保存的密鑰來解密所述TrE內的加密數據。

82．根據實施例57-81中任一實施例所述的方法，該方法還包括將基於證書的鑑定會話與所述用於HeNB確認的過程通過使兩個過程使用相同的或連續的公共協議會話的會話來進行結合。

83．根據實施例57-82中任一實施例所述的方法，其中所述設備確認包括通過公共協定會話在HeNB與使網路能進行HeNB的設備完整性確認的網路實體之間的交互。

84．根據實施例57-83中任一實施例所述的方法，該方法還包括將HeNB綁定的設備確認與基於EAP-AKA的客戶鑑定進行結合。

85．根據實施例57-84中任一實施例所述的方法，該方法還包括使用加密密鑰和用於TrE與HeNB其餘的之間訊息交換的憑證將TrE和HeNB進行結合。

86．根據實施例57-85中任一實施例所述的方法，其中所述在TrE與HeNB其餘的之間的訊息交換包括與設備鑑定相關的訊息交換。

87．根據實施例57-86中任一實施例所述的方法，其中所述密鑰和憑證在TrE內受保護。

88．根據實施例57-87中任一實施例所述的方法，該方法還包括在公共安全協議相同的或者連續的會話中，HeNB和TrE執行設備的預先指定的部分確認以及基於EAP-AKA的客戶鑑定。

89．根據實施例57-88中任一實施例所述的方法，該方法還包括將HeNB的設備確認與基於證書的客戶鑑定結合起來。

90．根據實施例57-89中任一實施例所述的方法，其中所述TrE包括密鑰對。

91．根據實施例57-90中任一實施例所述的方法，其中所述密鑰對包括私有部分和公共部分。

92．根據實施例57-91中任一實施例所述的方法，其中所述私有部分安全儲存在TrE內。

93．根據實施例57-92中任一實施例所述的方法，其中所述公共部分對HeNB可用。

94．根據實施例57-93中任一實施例所述的方法，該方法還包括HeNB的製造商產生所述密鑰對；以及提供使公共密鑰對HeNB可用所需要的證書。

95．根據實施例57-94中任一實施例所述的方法，該方法還包括通過使用基於EAP-AKA的鑑定的加密方法來建立確認和鑑定的結合。

96．根據實施例57-95中任一實施例所述的方法，該方法還包括HeNB用來自所述證書的公共密鑰來加密響應；並將該加密資料轉發給所述TrE。

97．根據實施例57-96中任一實施例所述的方法，其中所述回應是IKE_AUTH回應。

98．根據實施例57-97中任一實施例所述的方法，該方法還包括所述TrE然後加密所述資料；以及計算將所述HeNB向鑑定、授權和收費(AAA)伺服器進行鑑定所需要的EAP-AKA回應(RES)參數。

99．根據實施例57-98中任一實施例所述的方法，該方法還包括所述HeNB使用所述公共密鑰來加密計算TrE中的AUTH參數所需要的資料。

100．根據實施例57-99中任一實施例所述的方法，該方法還包括所述TrE加密所述資料；以及計算將所述HeNB向所述SeGW鑑定所需要的AUTH參數。

101．根據實施例57-100中任一實施例所述的方法，該方法還包括將設備完整性和設備ID加密地進行結合。

102．根據實施例57-101中任一實施例所述的方法，其中所述設備完整和設備ID的加密結合由所述TrE和HeNB執行。

103．根據實施例57-102中任一實施例所述的方法，其中所述TrE和所述HeNB分別裝備了公共密鑰對。

104．根據實施例57-103中任一實施例所述的方法，其中所述TrE和所述HeNB分別裝備了對稱共用的密鑰。

105．根據實施例57-104中任一實施例所述的方法，其中所述TrE和所述HeNB使用密鑰來保護通信和相互鑑定。

106．根據實施例57-105中任一實施例所述的方法，其中用於設備鑑定的IKEv2協議被用於結合所述TrE和HeNB。

107．根據實施例57-106中任一實施例所述的方法，其中所述設備完整性通過將設備完整性確認過程和設備鑑定連接在一起來與設備ID密切關聯。

108．根據實施例57-107中任一實施例所述的方法，其中所述設備完整性確認和設備鑑定在受保護的TrE中進行。

109．根據實施例57-108中任一實施例所述的方法，其中所述TrE是受保護的、可信的實體。

110．根據實施例57-109中任一實施例所述的方法，其中所述TrE執行設備完整性確認和設備鑑定過程。

111．根據實施例57-110中任一實施例所述的方法，其中所述IKEv2協議的會話，或者緊隨其後的會話被用於設備完整性確認和設備鑑定。

112．根據實施例57-111中任一實施例所述的方法，該方法還包括將設備確認過程結合到新的訊息交換中。

113．根據實施例57-112中任一實施例所述的方法，其中所述新的請求和回應交換發生在另一個類似的為設備鑑定而進行交換之前。

114．根據實施例57-113中任一實施例所述的方法，其中被設備鑑定使用的請求和回應交換被用於設備確認過程。

115．根據實施例57-114中任一實施例所述的方法，其中設備完整性確認需要的額外資料內嵌在選定的訊息欄位內。

116．根據實施例57-115中任一實施例所述的方法，其中設備完整性需要的資料包括關於本地自動完整性校驗或半自動確認的結果的簽名的狀態。

117．根據實施例57-116中任一實施例所述的方法，其中所述訊息欄位包括受保護的通知欄位。

118．根據實施例57-117中任一實施例所述的方法，該方法還包括將設備確認過程結合到存在的訊息交換中。

119．根據實施例57-118中任一實施例所述的方法，該方法還包括將所述設備確認過程結合到新的請求和回應交換中。

120．根據前述任一實施例所述的方法，該方法還包括執行完整性校驗及使用完整性校驗中產生的資訊來影響網路決定。

121．根據前述任一實施例所述的方法，其中資訊元素包括製造商和完整性演算法。

122．根據前述任一實施例所述的方法，其中元件特定的資訊元素包括元件描述、元件標識(ID)和可信的參考值(TRV)。

123．根據前述任一實施例所述的方法，其中模組特定的資訊元素包括模組描述、模組標識(ID)、功能描述、功能ID、組件ID、發佈版本和嚴重性。

124．根據前述任一實施例所述的方法，其中所述嚴重性指示了完整性校驗失敗的影響。

125．根據前述任一實施例所述的方法，其中所述嚴重性分級為範圍1到4。

126．根據前述任一實施例所述的方法，其中嚴重性1表明對H(e)NB功能性的高影響和可能保證停止操作和回退碼影像(FBC)能發送遇險信號給預先指定的H(e)MS。

127．根據前述任一實施例所述的方法，其中嚴重性2表明受限制的H(e)NB功能性。

128．根據前述任一實施例所述的方法，其中嚴重性3可能不會影響核心功能性，並且模組/功能的失敗被韌體更新過程替換並通過重新啟動被確認。

129．根據前述任一實施例所述的方法，其中嚴重性4可能不會影響核心功能性，並且失敗的模組能通過常態的韌體更新被替換。

130．根據前述任一實施例所述的方法，其中在自動確認過程中，所述設備完整性校驗在本地進行。

131．根據前述任一實施例所述的方法，其中如果完整性校驗失敗，則向室內移動站(H(e)MS)發送遇險信號。

132．根據前述任一實施例所述的方法，其中在半自動確認過程中，完整性校驗失敗的功能性的列表被報告給個人視頻編碼器(PVE)。

133．根據前述任一實施例所述的方法，其中在完整性校驗過程中，一個模組只被校驗一次。

134．根據前述任一實施例所述的方法，其中一個模組只在一個元件中出現。

135．根據前述任一實施例所述的方法，其中一個模組可以在兩個功能之間共用。

136．根據前述任一實施例所述的方法，其中每一模組有一個相關聯的功能性，並且失敗的功能性的列表能被推導出來並被用半自動確認(SAV)發送到個人視頻編碼器(PVE)。

137．根據前述任一實施例所述的方法，其中功能性識別字(ID)提供了模組的類別。

138．根據前述任一實施例所述的方法，其中模組根據產生的影像進行分類。

139．根據前述任一實施例所述的方法，其中一組模組包含同一元件識別字(ID)並且共同進行完整性校驗。

140．根據前述任一實施例所述的方法，其中具有一個元件識別字(ID)的模組以不同的功能性識別字(ID)進行分類。

141．根據前述任一實施例所述的方法，其中模組識別字(ID)被用於追蹤變化的軟體模組並且未被標準化。

142．根據前述任一實施例所述的方法，其中模組根據功能性和完整性校驗量子進行分類。

143．根據前述任一實施例所述的方法，其中具有同一元件識別字(ID)的所有模組有一個可信的參考值，並且如果該可信的參考值失敗，則該失敗的元件的所有模組用於確定失敗的功能性的列表並被傳遞給室內移動站(H(e)MS)或者個人視頻編碼器(PVE)。

144．根據前述任一實施例所述的方法，其中功能性的列表與元件相關聯。

145．根據前述任一實施例所述的方法，其中元件被按照他們載入的順序進行組織。

146．根據前述任一實施例所述的方法，其中所述完整性校驗針對部分影像物件檔進行，並且如果所述影像物件檔沒有通過完整性校驗，則抽取出失敗的分段名。

147．根據前述任一實施例所述的方法，其中使用者端設備(CPE)被用於下載可信的參考到所述H(e)NB上，並且該可信的參考被網路運營商的簽名密鑰進行了數位簽名。

148．根據前述任一實施例所述的方法，其中一旦接收到包含可信的參考值的簽名包，所述H(e)NB就解密所述簽名並確認接收到的可信的參考值的可靠性和完整性。

149．根據前述任一實施例所述的方法，其中可信的參考值在數字簽名之前為保密性而進行了加密。

150．根據前述任一實施例所述的方法，其中可信的參考值被添加到軟體模組二進位影像的一部分。

151．根據前述任一實施例所述的方法，其中所述H(e)NB和室內移動站H(e)MS支持安全插口層/傳輸層安全性(SSL/TLS)並使用基於證書的鑑定。

152．根據前述任一實施例所述的方法，其中基於TR069的架構支援基於證書的鑑定。

153．根據前述任一實施例所述的方法，其中所述H(e)NB被用ManagmentServer.URL參數中的系統預設室內移動站(H(e)MS)統一資源定位器(URL)來進行配置。

154．根據前述任一實施例所述的方法，其中所述H(e)NB支援局域網(LAN)側ManagmentServer.UR配置。

155．根據前述任一實施例所述的方法，其中安全閘道SeGW統一資源定位器(URL)是一個參數。

156．根據前述任一實施例所述的方法，其中在自動確認過程中，數位簽名或訊息被用私有密鑰進行簽名。

157．根據前述任一實施例所述的方法，其中在自動確認過程中，資訊不被發送到網路實體。

158．根據前述任一實施例所述的方法，其中針對用於產生可信的參考完整性度量或可信的參考值的演算法，最低需求被標準化。

159．根據前述任一實施例所述的方法，其中可信的參考值由可信的第三方產生並被數字簽名。

160．根據前述任一實施例所述的方法，其中本地完整性資料初始化被執行。

161．根據前述任一實施例所述的方法，其中初始的配置資料的提供被執行。

162．根據前述任一實施例所述的方法，其中參考完整性度量變為可信的參考值。

163．根據前述任一實施例所述的方法，其中設備配置資料表在設備的安全記憶體中被維護並被授權過的一方存取。

164．根據前述任一實施例所述的方法，其中設備配置資料被H(e)NB加密和解密。

165．根據前述任一實施例所述的方法，其中在安全啟動過程中，產生的摘要被與設備配置資料表中的指定的值進行比較。

166．根據前述任一實施例所述的方法，其中如果設備配置資料表期滿，則所述H(e)NB開始韌體更新過程以從補救伺服器上拉取資料。

167．根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)發起遠端程序呼叫(RPC)並更新ManagmentServer.URL。

168．根據前述任一實施例所述的方法，其中檔傳輸協議安全(FTPS)被用於傳輸檔。

169．根據前述任一實施例所述的方法，其中所述設備完整性校驗在自動確認中失敗並且本地遇險標誌被設置並且回退碼(FBC)被儲存在設備中。

170．根據前述任一實施例所述的方法，其中遇險信號包含了設備完整性校驗失敗的詳細資訊。

171．根據前述任一實施例所述的方法，其中檔傳輸協議(FTP)伺服器被與室內移動站(H(e)MS)合併。

172．根據前述任一實施例所述的方法，其中在半自動確認(SAV)過程中，所述H(e)NB與安全閘道(SeGW)通過不安全的鏈路進行交互。

173．根據前述任一實施例所述的方法，其中安全閘道(SeGW)只允許鑑定過的H(e)NB存取到網路；根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)作為所述H(e)NB管理伺服器並提供對補救的支援。

174．根據前述任一實施例所述的方法，其中在SAV中所述H(e)NB進行預先指定的元件的完整性校驗。

175．根據前述任一實施例所述的方法，其中在SAV中元件的確認通過比較來自完整性演算法的摘要輸出和設備配置表中指定的值而在本地進行。

176．根據前述任一實施例所述的方法，其中所述H(e)NB的傳輸元素(TrE)進行預先定義的元件的完整性校驗。

177．根據前述任一實施例所述的方法，其中所述H(e)NB通過證書交換用安全閘道(SeGW)建立網際網路密鑰交換(IKE)安全聯盟。

178．根據前述任一實施例所述的方法，其中在元件的本地完整性確認之後，所述元件被所述設備載入並執行。

179．根據前述任一實施例所述的方法，其中網際網路密鑰交換元素(IKE)被發送以建立安全聯盟，該安全聯盟包含了用於加密演算法的安全參數索引。

180．根據前述任一實施例所述的方法，其中安全閘道(SeGW)發送回應給網際網路密鑰交換(IKE)。

181．根據前述任一實施例所述的方法，其中所述H(e)NB用IKE_AUTH_REQ來發送證書以用於相互鑑定。

182．根據前述任一實施例所述的方法，其中安全閘道(SeGW)評估所述H(e)NB的鑑定憑證並提取功能性識別字的列表。

183．根據前述任一實施例所述的方法，其中如果鑑定確認成功，則安全閘道(SeGW)發送指示給所述H(e)NB。

184．根據前述任一實施例所述的方法，其中如果鑑定確認失敗，則安全閘道(SeGW)發送指示給所述H(e)NB。

185．根據前述任一實施例所述的方法，其中所述SeGW發送失敗的功能性的列表給個人視頻編碼器(PVE)。

186．根據前述任一實施例所述的方法，其中所述PVE確定行動，該行動包括隔離所述設備、提供完全存取、提供部分存取或者請求室內移動站(H(e)MS)為補救而干涉。

187．根據前述任一實施例所述的方法，其中所述PVE將決定通知給所述SeGW。

188．根據前述任一實施例所述的方法，其中個人視頻編碼器(PVE)發送通知給室內移動站(H(e)MS)以啟動補救和失敗的模組的列表。

189．根據前述任一實施例所述的方法，其中個人視頻編碼器(PVE)發送關於補救的通知給所述H(e)NB。

190．根據前述任一實施例所述的方法，其中安全閘道(SeGW)指示設備完整性評估的結果給所述H(e)NB。

191．根據前述任一實施例所述的方法，其中傳輸元素(TrE)將完整性驗證委託給外部實體。

192．根據前述任一實施例所述的方法，其中所述H(e) NB包括本地時間伺服器，該本地時間伺服器使用網路時間協定(NTP)來同步時間。

193．根據前述任一實施例所述的方法，其中鑑定證書和SAV中的本地確認的結果以IKE_AUTH_REQ訊息進行發送。

194．根據前述任一實施例所述的方法，其中安全閘道(SeGW)在將該表傳遞給個人視頻編碼器(PVE)之前過濾一系列失敗的模組。

195．根據前述任一實施例所述的方法，其中所述H(e)NB與室內移動站(H(e)MS)通過安全閘道或者通過網際網路連接而進行交互以支持補救。

196．根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)調用遠端程序呼叫(RPC)來指示所述H(e)NB上傳失敗的功能性的列表和錯誤碼的列表。

197．根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)指示檔伺服器準備上傳失敗的功能性的列表。

198．根據前述任一實施例所述的方法，其中所述H(e)NB調用過程來上傳包含了失敗的功能性列表的檔。

199．根據前述任一實施例所述的方法，其中檔伺服器在評估上傳的檔之後，發送Download_Package_Ready訊息給室內移動站(H(e)MS)。

200．根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)調用遠端程序呼叫(RPC)並提供設備配置表的統一資源定位器(URL)。

201．根據前述任一實施例所述的方法，其中所述H(e)NB與檔傳輸協議(FTP)檔伺服器相連並下載韌體影像和設備配置表。

202．根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)一旦接收到成功下載的回應，就調用重新啟動過程。

203．根據前述任一實施例所述的方法，其中所述H(e)NB一旦接收到成功下載的回應，就重置本地遇險標誌。

204．根據前述任一實施例所述的方法，其中室內移動站(H(e)MS)從安全閘道(SeGW)接收指示所述設備成功啟動的訊息。

205．根據前述任一實施例所述的方法，其中如果在安全啟動過程中，完整性校驗被載入、執行並且鑑定成功進行，則所述H(e)NB與安全閘道進行通信。

206．根據前述任一實施例所述的方法，該方法還包括傳送本地完整性校驗的結果。

207．根據前述任一實施例所述的方法，該方法還包括將所述本地完整性校驗的結果轉發給個人視頻編碼器(PVE)。

208．根據前述任一實施例所述的方法，其中H(e)NB用IKEv2 NOTIFY訊息發送失敗的功能性的列表和製造商特定的錯誤碼的列表給所述SeGW。

209．根據前述任一實施例所述的方法，其中SeGW將所述失敗的功能性的列表轉發給個人視頻編碼器(PVE)。

210．根據前述任一實施例所述的方法，其中PVE決定SeGW行動、H(e)NB行動，並將所述行動的列表轉發給所述SeGW。

舉例來說，恰當的處理器包括：通用處理器、專用處理器、傳統處理器、數位信號處理器(DSP)、多個微處理器、與DSP核心相關的一個或多個微處理器、控制器、微控制器、特定功能積體電路(ASIC)、現場可編程閘陣列(FPGA)電路、任何一種積體電路(IC)和/或狀態機。

與軟體相關的處理器可以用於實現一個射頻收發機，以便在無線發射接收單元(WTRU)、使用者設備(UE)、終端、基地台、無線電網路控制器(RNC)或者任何主機電腦中加以。WTRU可以與採用硬體和/或軟體形式實施的模組結合使用，例如照相機、視訊攝影機模組、視訊電話、揚聲器電話、振動設備、揚聲器、麥克風、電視收發器、免提耳機、鍵盤、藍牙®模組、調頻(FM)無線單元、液晶顯示器(LCD)顯示單元、有機發光二極體(OLED)顯示單元、數位音樂播放器、媒體播放器、電動遊戲機模組、網際網路瀏覽器和/或任何無線區域網路(WLAN)模組或者超寬頻(UWB)模組。

雖然本發明的特徵和元特在較佳的實施方式中以特定的結合進行了描述，但每個特徵或元件可以在沒有所述較佳實施方式的其他特徵和元件的情況下單獨使用，或在與或不與本發明的其他特徵和元件結合的各種情況下使用。本發明提供的方法或流程圖可以在由通用電腦或處理器執行的電腦程式、軟體或韌體中實施，其中所述電腦程式、軟體或韌體是以有形的方式包含在電腦可讀儲存媒體中的。電腦可讀儲存媒體的例子包括唯讀記憶體(ROM)、隨機存取記憶體(RAM)、暫存器、快取記憶體、半導體記憶體裝置、諸如內部硬碟和可移動磁碟這樣的磁性媒體、磁光媒體和如CD-ROM光碟和數位通用光碟(DVD)這樣的光媒體。