執(zhí)行wtru的確認的方法以及設備的制作方法
【專利摘要】本發(fā)明公開了一種執(zhí)行WTRU的確認的方法以及設備。該方法包括：測量WTRU的至少一個預先指定組件的完整性測量；獲取WTRU的組件的可信參考值；使用位于WTRU中的TrE執(zhí)行組件的完整性檢查，并存儲完整性檢查結(jié)果；完整性檢查包括TrE比較完整性測量與組件的可信參考值；使用TrE在WTRU上執(zhí)行安全啟動檢查，并存儲安全啟動檢查結(jié)果；啟動檢查確定組件是否達到安全啟動的狀態(tài)，啟動檢查結(jié)果包括當組件沒有達到安全啟動的狀態(tài)時的指示；使用TrE基于完整性檢查結(jié)果和安全啟動檢查結(jié)果形成確認消息；使用TrE將確認消息從WTRU轉(zhuǎn)發(fā)到PVE，PVE在WTRU外部。
【專利說明】執(zhí)行WTRU的確認的方法以及設備
[0001]本申請是申請?zhí)枮?01080010759.8、申請日為2010年03月05日、發(fā)明名稱為“無
線設備的平臺確認和管理”的中國發(fā)明專利申請的分案申請。
[0002]相關申請的交叉引用
[0003]本申請要求2009年3月6日提交的美國臨時申請N0.61/158，242、2009年4月28日提交的美國臨時申請N0.61/173，457、2009年6月30日提交的美國臨時申請N0.61/222，067、2009年8月21日提交的美國臨時申請N0.61/235，793的權益，其全部內(nèi)容通過引入結(jié)合于此如同在此全部提出。本申請與同時提交的題為“Method and ApparatusFor H(e)NB Integrity Verification and Validation” 的美國專利申請 N0.12/718，572相關，其通過引用的方式結(jié)合于此如圖在此全部提出。
【技術領域】
[0004]本申請涉及通信。
【背景技術】
[0005]移動通信網(wǎng)絡的現(xiàn)有技術或標準化技術不能向網(wǎng)絡提供對設備整體性進行認證和確認(validate)的方法，或提供對這些設備進行管理和規(guī)范的方法。同樣，需要連接至網(wǎng)絡的設備也不能確認其所連接的網(wǎng)絡實際是否為有效的或可信的供應商網(wǎng)絡。

【發(fā)明內(nèi)容】

[0006]公開了用于實現(xiàn)平臺確認和管理(PVM)的方法、組件和裝置。PVM的實施使得平臺確認實體的功能和操作能夠通過設備管理系統(tǒng)(例如家庭節(jié)點B管理系統(tǒng))對設備進行遠程管理。示例的PVM操作使設備在允許連接和接入核心網(wǎng)之前處于安全目標狀態(tài)。
【專利附圖】

【附圖說明】
[0007]在以下的描述中，可結(jié)合附圖，以示例的方式獲得更詳細的理解，在附圖中:
[0008]圖1不出了表不可信子系統(tǒng)的域分隔的不例框圖；
[0009]圖2示出了表示通過組織和技術方法在平臺間調(diào)解信任的示例框圖；
[0010]圖3示出了與增強型家庭節(jié)點B (H(e)NB)之間的半自主確認的示例流程圖；
[0011]圖4示出了四步安全啟動方法的示例流程圖；
[0012]圖5A示出了示例實體集合及它們之間的關系和用于平臺確認和管理(PVM)的接口的框圖；
[0013]圖5B示出了示例實體集合及它們之間的關系和用于PVM的接口的另一個框圖；
[0014]圖6A、6B和6C示出了使用了平臺確認實體的示例確認方法的信令圖；
[0015]圖7是示出了顯示H(e)NB通信場景的示例框圖；
[0016]圖8是示出了 H(e)NB中“弱”可信環(huán)境的示例框圖；
[0017]圖9A示出了間接設備連接的示例框圖和方法；[0018]圖9B示出了直接設備連接的示例框圖和方法；
[0019]圖10示出了處理各個證書的示例流程圖；
[0020]圖1lA示出了在整體性確認失敗之后，通過由回退代碼庫實現(xiàn)設備修正(remediation)的示例確認方法；
[0021]圖1lB示出了根據(jù)圖1lA的方法的示例流程圖；
[0022]圖12示出了用于參考完整性度量屏蔽報頭的示例格式；
[0023]圖13示出了使用了虛擬平臺配置登記值的確認的示例流程圖；
[0024]圖14示出了在完全半自主確認期間加載組件時，模塊分級的示例圖；和
[0025]圖15示出了分別用于提供、執(zhí)行和實施PVM的無線發(fā)射/接收單元和基站的示例功能性框圖。
【具體實施方式】
[0026]當下文中涉及時，術語“無線發(fā)射/接收單元(WTRU)”包括但不限于用戶設備(UE)、移動站、固定或移動用戶單元、尋呼機、蜂窩電話、個人數(shù)字助理(PDA)、計算機或任何其他類型的能夠在無線環(huán)境中進行操作的設備。當下文中涉及時，術語“基站”包括但不限于節(jié)點B、站點控制器、接入點(AP)、網(wǎng)關、用戶端設備(CPE)或任何其他類型的能夠在無線或有線環(huán)境中進行操作的接口設備。當下文中涉及時，術語“HMS”包括但不限于家庭節(jié)點B管理系統(tǒng)(HMS)、家庭增強型節(jié)點B管理系統(tǒng)(HeMS)，其中以上兩者可統(tǒng)稱為H(e)MS，設備管理系統(tǒng)(DMS)、配置服務器(CS)和自動配置服務器(ACS)，或任何其他類型的管理“基站”的配置或功能的系統(tǒng)。術語“WTRU”和“基站”不相互排除。舉例來講，WTRU可以是增強型家庭節(jié)點B(H(e)NB)。當下文中涉及時,術語“理論信息安全(informat ion-theoretical Iysecure)”包括但不限于完全安全、無條件安全和接近理論的信息安全。當下文中涉及時，術語“信任”、“可信的”和“值得信賴的”及其變形，表示對單元是否能以特定方式工作進行評估的可計量和可觀察的方式。
[0027]公開了用于實現(xiàn)平臺確認和管理(PVM)的方法和裝置。PVM通過設備管理系統(tǒng)(例如家庭節(jié)點B管理系統(tǒng)(HMS ))使平臺確認實體(PVE )的功能和操作能夠?qū)υO備進行遠程管理。PVM操作使設備在允許連接和接入核心網(wǎng)(CN)之前處于安全目標狀態(tài)。
[0028]PVM操作是完備的(self-contained)，并且在不同的技術環(huán)境中同時允許多種變形和多種實施方式。雖然在需要描述實施例時，針對特定情況會提及示例的協(xié)議，例如互聯(lián)網(wǎng)密鑰交換(IKE)，但并不能將其解釋為對本發(fā)明整個范圍的約束或限制。雖然在一些地方使用H(e)NB作為例子，但并不能將PVM限制為H(e)NB。可不偏離主旨地直接進行技術改造，將PVM擴展到機器對機器(M2M)和其他無線和/或網(wǎng)絡設備。
[0029]描述是自上而下的，因為始于開始的結(jié)構(gòu)假定了大多數(shù)可信計算技術核心概念的可用性，該可信計算技術涉及但不限于由可信計算群組(TCG)所規(guī)定的技術標準。例如，此處所描述的實施例基于由可信環(huán)境(TrE)和參考完整性度量(RIMs)所執(zhí)行的安全啟動來為PVM的所有操作和方法構(gòu)建基礎。這并不排除基于較低信任度的技術的進一步改變的實現(xiàn)方式。其他實施例還可在多個PVM步驟中不使用RIMs。
[0030]通常，在技術系統(tǒng)中，PVM包含了集成到技術系統(tǒng)中的信任綜合定義中的信任語句(not ion )，其中重點是在系統(tǒng)中建立信任的方法。PVM使用任務的分散和分隔作為核心范例。這應演進的通信網(wǎng)絡和互聯(lián)網(wǎng)所需而實現(xiàn)了可調(diào)節(jié)(scalable)的信任，在所述演進的通信網(wǎng)絡和互聯(lián)網(wǎng)中，節(jié)點更加多樣而連接時間更短暫。
[0031]以下對信任的一致的操作解釋可用于技術系統(tǒng)(例如PVM)之間以及技術系統(tǒng)與人類之間的關系和交互:“如果實體可預測地并可觀察地為了預定目的而按照預期方式進行操作，則該實體可信”。該操作解釋包括三個顯著特征，即，可預測性、可觀察性和環(huán)境性。
[0032]可預測性表示對系統(tǒng)的預先認知，該預先認知可用于a)評價與該系統(tǒng)進行交互所產(chǎn)生的風險，和b)通過對觀察結(jié)果進行推斷，而在交互過程中獲得系統(tǒng)情況?？捎^察性特指通過該特征可在交互過程中獲得系統(tǒng)情況。其與可預測性緊密相關，從觀察結(jié)果中，結(jié)合預測，可對系統(tǒng)狀態(tài)和下一步的行動做出進一步判斷。環(huán)境性是指描述了與系統(tǒng)進行交互的環(huán)境的信息，在該環(huán)境中，可以做出預測和進行觀察。總的來說，三者實現(xiàn)了對其可信度的估計，或反之，能夠?qū)ζ鋵换嶓w所產(chǎn)生的威脅進行估計。
[0033]由于缺少建立操作信任的方法，而在信任和強制(enforcement)之間造成了概念上的差異。隨著互聯(lián)系統(tǒng)多樣化，已經(jīng)不再限于客戶-服務器的關系，這種問題變得更加突出。在這種情況下，考慮到現(xiàn)有(安全)技術的發(fā)展水平，無論是強制還是信任的操作方面都不能實現(xiàn)。系統(tǒng)缺少a)用來建立可操作的信任的普遍的技術方法，b)用于強制的首要基礎結(jié)構(gòu)，和c)用于將有關可信性和適當?shù)陌踩燃壍男畔l(fā)送到外部實體的方法。只有上述基本結(jié)構(gòu)塊才能夠在系統(tǒng)中實現(xiàn)可反映現(xiàn)實需求的信任和強制的動態(tài)平衡，也就是可調(diào)節(jié)的任。
[0034]PVM也是根據(jù)上述構(gòu)造塊而建立的?？尚畔到y(tǒng)的結(jié)構(gòu)塊構(gòu)造了其信任邊界，并且有時提供了可擴展該邊界的方法，并通過使其性能和操作在一定程度內(nèi)可預測和可觀察，而向外部實體傳送該信任。構(gòu)造塊可包括(硬件)安全錨、信任根(RoT)、可信(子)系統(tǒng)，及所有關系、安全存儲及路徑、授權、認證及安全啟動進程和證明。通過把上述方法相結(jié)合，可以以多種方式構(gòu)建結(jié)合了信任和強制的特征的系統(tǒng)和各種組件，從而實現(xiàn)可在這兩個極端之間進行調(diào)節(jié)的技術。下面描述基本的功能構(gòu)造塊。
[0035]硬件安全錨對于保護系統(tǒng)性能非常重要。硬件安全錨是系統(tǒng)中用于通過硬件手段來保護其不受到未授權的訪問的部分，從而有效地降低對該其的攻擊威脅，其中所述硬件手段已知對預期目的是足夠安全的。特別是，其保持用于其安全操作的RoT。該RoT是抽象的系統(tǒng)組件，其實現(xiàn)a)確保內(nèi)部系統(tǒng)操作的安全，和b)以安全和認證的方式向外部實體告知系統(tǒng)的屬性和/或標識(單個地或作為組成員，例如構(gòu)造和型號)。
[0036]一個系統(tǒng)為不同目的可包含多個RoT。例如RoT可以是結(jié)合了其可信第三方數(shù)字證書的非對稱密鑰對。同時，蜂窩網(wǎng)絡的用戶識別模塊(SM)中的對稱秘密也可看作是以SIM卡來實現(xiàn)的封閉的可信系統(tǒng)中的RoT。
[0037]其次，系統(tǒng)中的認為可信的(即為了預定目的而按照清楚的方式進行操作)功能構(gòu)造塊組成了該系統(tǒng)的可信計算基礎(TCB)。該TCB所包含的系統(tǒng)組件在域中調(diào)用系統(tǒng)時和在操作期間，不能檢測其操作可信特征，而只能被例如兼容和一致性檢測和證明的帶外進程檢測。這種證明通常是由獨立的評估器來執(zhí)行的，例如是根據(jù)所建立的安全評價標準的，代表TCB特定技術組件的制造商或整體TCB的制造商。為了使這種證明有用，TCB的每個組件都應該具有將其標識為是這種證明技術組件的信息。
[0038]具有所述安全錨、RoT和TCB的系統(tǒng)稱為可信系統(tǒng)(TS)。這里對通常可信平臺的概念有一點改進，通常的可信平臺指的是“具有通常使用內(nèi)嵌硬件的方式的可信組件的計算平臺，該計算平臺使用所述可信組件來建立用于軟件進程的信任基礎”。當TS中存在一個或多個可信系統(tǒng)時，這些可信系統(tǒng)稱為可信子系統(tǒng)(TSS)。其例子包括個人計算機平臺上的虛擬執(zhí)行環(huán)境，該個人計算機平臺從主機的可信平臺模塊硬件(TPM)接收特定信任。另一個例子是結(jié)合了其TCB的可信引擎的規(guī)定。在下文中，除非明確指出，否則“TS”可以互換用作“TS或TSS”的縮略語。TS可以在如圖1所示的各種設備中實現(xiàn)。
[0039]下面，對TS中總稱為術語可信資源(TR)的各種能力、進程和結(jié)構(gòu)組件進行描述。TR通?？梢苑譃?1)屬于TCB的TR ;和2) TCB外的TR。后者的例子是操作系統(tǒng)的可信組件和通過使用TCB性能而構(gòu)建在TCB上的可信應用程序。對TCB中TR可信度的認定依賴于TCB所定義的安全，而其他TR的可信度至多可以從來自TCB的可信度得到。在這種情況下，TCB必須將能夠允許對信任邊界(即能夠在指定環(huán)境中認為可信的TS組件的總數(shù))進行擴展的特定內(nèi)部TR提供給TCB外的TR，例如如下所述的確認或安全的啟動。TCB內(nèi)的TR通常與所述RoT共用相同的硬件保護，例如位于同一塊防干擾芯片上。TCB外的TR可以以軟件內(nèi)的邏輯單元來實現(xiàn)。注意，信任邊界，尤其是涉及TCB外的TR的信任邊界，可以是短時的。其可在一段時間內(nèi)為特定目的而存在，并可以在之后不再存在。
[0040]用于擴展TCB信任邊界的過程的通用模型是驗證(verification)。其本身就是用來執(zhí)行驗證過程的TR。將其標識為驗證進程和相應的TR驗證實體或驗證器，以區(qū)別于由外部實體(即確認器)對TS進行的確認過程。驗證作為進程包括在信任邊界中至少以兩種不同形式出現(xiàn)的新組件。首先，驗證器在其初始化時測量新組件。也就是說，該組件、該組件的狀態(tài)和配置是唯一標識出的。之后存儲該測量結(jié)果。作為其擴展，驗證器可以將該測量結(jié)果與參考值進行比較，并判斷是否擴展信任邊界。也就是說，驗證器可以做出并執(zhí)行策略決定。從操作的角度來說，由于在完成驗證過程后，可認為其處于特定的預定狀態(tài)，因此驗證對應于TS的可預測性。而另一方面，確認則使該屬性可觀察，從而可信。這表示，存在報告實體將驗證結(jié)果發(fā)送給另一方。第三，由該報告實體所執(zhí)行的中間步驟為證明。證明是驗證的邏輯結(jié)果，還是確認的邏輯前提。證明是確保所測量信息的準確性的進程，從而可靠方一確認器一一可以使用該信息來決定其是否該信任遠程TS。驗證、證明和確認是可操作信任的核心概念，其與TS的存在周期緊密相聯(lián)。
[0041]TS由被授權訪問信任邊界內(nèi)的特定TR (例如由RoT)的實體(個人或其他技術系統(tǒng))所具有。該所有關系可以通過直接地物理具有TS而隱式的存在，即該平臺包含TS，或例如通過特定憑證(credential)對所有者進行認證而顯式的表明。在可信計算群組(TCG)可信平臺模塊(TPM)規(guī)范的環(huán)境中，提供這種認證數(shù)據(jù)稱為獲得所有權。直接與TS進行交互的所有者稱為本地所有者，而要通過任何方式中轉(zhuǎn)，例如通過通信網(wǎng)絡中轉(zhuǎn)，來與TS進行交互的所有者稱為遠程所有者。當TS中包含多個TSS時，每個TSS都可以具有相同或不同的所有者。
[0042]圖1表示若干個TSSl 10、130、150和170的計算域的分隔。TSSl 10、130、150和170分別包括專用移動可信模塊(MTM) 112、132、152和172。移動電話工作組(MPWG)規(guī)范的硬件安全錨包含所提及的RoT、TR (可信資源114、134、154和174)和可信服務116、136、156和176。通常的軟件服務和組件118、138、158和178分別位于信任邊界120、140、160和180之外。所謂的可信引擎122、142、162和182 (所有這些都位于安全計算環(huán)境中)依賴RoT在不同TSS110、130、150和170之間分別特別提供分隔和可控通信。在使用域間確認和授權的條件下，TSS可以與其他TSS共享TR，甚至共享MTM的功能。只要至少存在一個硬件保護的RoT (從該RoT生成基于軟件的MTM的RoT)，就可以以軟件的形式來實現(xiàn)可信引擎以及一些MTM。每個TSS可由本地或遠程相關方(stakeholder)或所有者來控制。在移動設備的存在周期中，并不是所有相關方TSS都存在，且存在進程使得(遠程)相關方能夠初始化新TSS的創(chuàng)建并獲得其所有權。
[0043]PVM部分依賴于信任的建立。在信任與強制之間，主要的連接概念是任務分隔。任務分隔通常認為是涉及強制的任務。但是其與信任有天然的聯(lián)系。依賴方只有在其操作可信時，才會將強制委托給其他系統(tǒng)。在TS間建立操作信任依賴于為實現(xiàn)可觀測性和預建立可預測性而進行的可控信息交換。后者只能在TS之外完成。
[0044]圖2所表示的示例模型展示了向TS200、202提供組織保證的外部實體的角色。TS200、202包括正常應用程序260、262，該正常應用程序位于信任邊界270、272之外。在信任邊界270、272內(nèi)，有TCB216、218，該TCB反過來包括RoT208、210和TR212、214。信任邊界270、272可進一步包括可信操作系統(tǒng)230、232或其中需要保護的部分以及可信應用程序234,236ο
[0045]TS200、202的安全屬性位于硬件信任錨204、206和RoT208、210中。當部署和操作系統(tǒng)時，上述技術組件是不能被檢測的。因此，其在設計和開發(fā)過程中需要接受安全評價。這是由獨立的機構(gòu)所執(zhí)行的，一旦評價成功，該機構(gòu)便向安全性重要組件的制造商頒發(fā)安全性證書。
[0046]除RoT208、210和信任錨204、206以外，安全性進程還可在TCB216、218中包括其他TR212、214，并涉及不同的證明機構(gòu)220、222。為了確保評價過程和不同證明機構(gòu)的質(zhì)量的一致性，其反過來由鑒定機構(gòu)224進行評定和證明，該鑒定機構(gòu)可以例如是半國有的或由國家承認的私人實體。該鑒定機構(gòu)224還可在證明機構(gòu)220、222之間提供連接信息。
[0047]證明機構(gòu)220、222或收到其通知的技術實體向TS200、202頒發(fā)供TR212、214所使用的憑證226、228。這些憑證226、228能證明其完整性和來源都是可證實的。最重要的例子是由制造商頒發(fā)給TPM的主RoT (EK)認可(endorsement)密鑰(EK)證書，以及平臺證書和其他組件的證書。之后還使用加密方法使從這些證書中所獲得的憑證和秘密都用于與外部實體(特別是其他TS)進行交互。TS200、202的確認240通常需要認證，并且在許多情況下，還需要保密。并且，具有從TS憑證中得到的信任的秘密和憑證對于操作系統(tǒng)230、232和可信應用程序234、236分別建立安全性關聯(lián)242、244來講是非常重要的，所述安全性關聯(lián)也就是能夠?qū)νㄐ盘峁┱J證、機密性和完整性的信道。在安全性關聯(lián)242、244之上，擴展信任邊界內(nèi)的應用程序可以與定義好的操作信任屬性建立起安全的通信信道。
[0048]調(diào)解(mediation)實體250促進在圖2所示的各種交互之間建立信任。調(diào)解實體250的一個例子是私人證明機構(gòu)(PCA)。調(diào)解實體250將關于TS可信度的基礎聲明發(fā)送至另一個TS或依賴方。調(diào)解實體將TCB216、218或所選組件(例如信任錨204、206等)標識為可信的且被證明的組件。此時，調(diào)解實體250需要知道由證明實體所頒發(fā)的證書，當從TS收到證書時驗證該證書，并向依賴方簽署保證聲明。調(diào)解實體250可以按照與公共密鑰基礎構(gòu)造(PKI)中的證明機構(gòu)(CA)類似的方式完成之后的安全性關聯(lián)和安全通信。
[0049]現(xiàn)在描述PVM所需的用于建立信任的構(gòu)造塊。[0050]本質(zhì)上，驗證是對TS的狀態(tài)變化進行記錄并控制為所期望的粒度(granularity)。同時，從開始到結(jié)束，其都要與TS所處的平臺的操作周期緊密相連。因此，實際的驗證方法大多與物理設備(例如WTRU)的一個或多個處理器所執(zhí)行的平臺的啟動進程和操作周期進行集成。
[0051]一種對TS進行內(nèi)部驗證的方法是認證啟動及在TS初始化時(例如WTRU上電時)使用TCB的能力來評定所加載或所啟動的軟件或硬件組件的可信度。認證啟動是通過在啟動TS的其它部件之前，先啟動RoT和TCB的特定功能來實現(xiàn)的。這些部件操作為用于測量的RoT (RTM)0這表示，之后所啟動或加載的組件都要經(jīng)過測量，即所述組件及其狀態(tài)和結(jié)構(gòu)在啟動后都要通過例如對硬件組件的內(nèi)嵌代碼和所加載的程序的(二進制)表示生成加密摘要值(例如，加密哈什值)而唯一地標識出。根據(jù)特定要求，可將測量值存儲在安全存儲器中。所述度量值與從其中追溯系統(tǒng)狀態(tài)所需的數(shù)據(jù)(例如軟件名稱和版本)一起形成TS的存儲測量日志(SML)。在PC平臺上，認證啟動可以包括從BIOS到操作系統(tǒng)(OS)加載器所有組件以及OS本身。
[0052]在認證啟動的一個例子中，由報告進程來測量系統(tǒng)狀態(tài)，其中TPM作為中心機構(gòu)來接收測量值并使用哈什值來計算該狀態(tài)的唯一表示。為了清楚起見，TPM可以接收I)應用程序或文檔的哈什值，即由外部(軟件)實施所計算出的應用程序的測量值，或2) TPM可以計算哈什值，即使用內(nèi)部哈什算法實施所算出的測量值本身。為此，TPM具有多個受保護的平臺配置寄存器(PCR)。從上電時系統(tǒng)進行初始化開始，對于每一個所加載的或所啟動的組件，都使用RTM向TPM報告其測量值，例如通過BIOS的哈什值，并安全地存儲在SML中。同時，由擴展過程對活動PCR進行更新，這意味著，將測量值附加在當前的PCR值上，通過該數(shù)據(jù)建立摘要值，并存儲在PCR中。這樣就建立了可傳遞的信任鏈，該信任鏈包含所啟動和加載的所有組件。如果單個PCR僅存儲一個值，則只能夠提供“足跡式”的完整性確認數(shù)據(jù)。該值使得確認器只能通過結(jié)合SML來重新計算該足跡才能驗證該信任鏈。
[0053]安全啟動是認證啟動的擴展。對于類似機頂盒或移動電話這種有待機和離線功能需求的設備來說，安全啟動具有特殊的重要性。能夠安全啟動的設備的共同特征是在其不能在例如網(wǎng)絡連接前將有關其信任度的證明向外部發(fā)送時，它們需要在一組可信的狀態(tài)中進行操作。在安全啟動中，TS具有本地驗證器(驗證實體)和本地強制器來監(jiān)管啟動進程，其同時建立了策略強制點(PEP)和策略決定點(PDP)，以控制安全啟動進程。該本地驗證器將新加載的或啟動的組件的測量值與位于TCB中的或由TR在TS中進行保護(例如位于受保護的存儲空間中)的可信參考值(TRV)進行比較，并決定其是否已加載、啟動或還未啟動。這樣，可以確保該系統(tǒng)啟動至定義的、可信的狀態(tài)。
[0054]可信參考數(shù)據(jù)是用于將確認數(shù)據(jù)與已知良好值進行比較的數(shù)據(jù)。構(gòu)成可信參考數(shù)據(jù)的這些值稱作可信參考值(TRV)。其最著名的例子是在TGG的MPWG規(guī)范中所定義的參考完整性度量(RM)。其實際可用作a)由平臺本身在安全啟動時使用，以確保只啟動那些度量值與TRV—致的組件，或b)由確認器使用，以將確認數(shù)據(jù)與已知良好值進行比較，從而在評價正在進行確認的平臺狀態(tài)。術語RM可以作為非限制性的示例用于描述可信參考數(shù)據(jù)。
[0055]這樣，可信參考數(shù)據(jù)通過對其特定的安全聲明而可信，其由確認器或代理使用所考慮的TRV來進行確認。這種可驗證的聲明可由例如數(shù)字證書來實現(xiàn)，該數(shù)字證書是由可信第三方(TTP)所頒發(fā)的例如成為RIM證書的數(shù)字證書?？尚艆⒖紨?shù)據(jù)的信任聲明還可以包含例如有關計算機或平臺的外部評價(例如，根據(jù)通用標準評價保護級別，EAL)的附加信
肩、O
[0056]需要重視TRV的雙重性。一方面，其在安全啟動進程中用于本地驗證。在該過程中，其由提供的基礎結(jié)構(gòu)的TRV所執(zhí)行，該結(jié)構(gòu)能夠例如通過向TS提供對應于所更新軟件的新TRV，來對所測量的組件進行更新。對于用來在安全啟動后確認TS的外部實體，則需要將所接收的確認數(shù)據(jù)(例如所謂事件結(jié)構(gòu))與所存儲的TRV進行比較，并驗證相關聯(lián)的TRV證書。這樣，TRV和相應的證書不僅對驗證很重要，對確認也很重要。
[0057]對于確認來講，證明信息的時新性十分重要。這就需要將驗證過程從啟動擴展到TS的操作時間，這在復雜的開放系統(tǒng)中是一項技術上很困難的任務。
[0058]所提到的任務分隔也存在于對TS進行確認的進程中。即，基于驗證結(jié)果，可以評價系統(tǒng)的可信度，并且可在確認過程中進行相應的策略決定。該進程中，在TS和確認器之間所進行的任務分隔將導致三種類型的確認?，F(xiàn)在首先描述各類確認所需的共同基本概念。
[0059]TS的確認進程必須得到確認標識的支持，其中該確認標識被展示給確認器。該確認標識必須直接或間接地來自RoT，即用于報告的RoT(RTR)。如果沒有調(diào)解器(mediator)則不能進行確認。確認標識的提供者必須聲明該確認標識的所有者為TS。提供確認標識是在標識管理(IdM)系統(tǒng)中提供標識的擴展。提供者必須對TS (包括TCB中一些或全部TR)的憑證進行檢查，以評定該TS是否處于針對確認為可信的狀態(tài)。并且，必須在安全進程中提供確認標識，例如專用安全信道中的安全協(xié)議。在遠程確認的情況下，該確認標識與TS的全局標識相一致。
[0060]使用唯一的永久確認標識進行確認對安全性是非常重要的。會由于各種目的而頻繁且任意地在多個確認器上進行確認。雖然所用的確認標識不會每個都易于與用戶標識相關，但是其通常能實現(xiàn)對TS的行為進行追蹤。由于安全原因，對一組或所有TS都使用相同的確認標識并不是解決該問題的選擇。這種組標識是攻擊/失敗的單點，也就是說，如果該組中的一個TS受到損害，則所有其他TS也不能進行確認了。另一種選擇是使用按確定的頻率所生成的或由RTR為每次確認所生成的短時確認標識,例如,每個啟動周期生成一個。
[0061]自主確認是在假設TS的驗證肯定已經(jīng)在本地完成(即，限制在該設備內(nèi)，也就是以不依賴于外部實體的方式)的基礎上，由外部確認器隱式地完成對TS的確認的過程。在這種情況下，假設在TS允許與外部或其他操作進行進一步的通信嘗試之前，已經(jīng)進行了成功的驗證。因此，在這種情況下，假設驗證進程是絕對安全的，這是因為沒有向外界提供該驗證的任何直接證據(jù)。外界進行如下假設:根據(jù)TS所進行規(guī)范和執(zhí)行的方式，TCB將阻止驗證失敗的TS執(zhí)行其他對外界可見的任務，例如將該TS自身連接至網(wǎng)絡，或從遠程實體獲取認證連接。自主確認將所有強制任務都放在TS上。
[0062]自主確認向TS使用了封閉不變的系統(tǒng)模型，該模型基本就是智能卡中所用的信任模型。TS使用TCB來對自身進行驗證，結(jié)果是二進制的“成功”或“失敗”值。而確認是間接的進程，TS在該進程中允許與外部進行特定交互，例如網(wǎng)絡附屬。一個典型的例子是由智能卡釋放認證秘密，例如密鑰。
[0063]僅依賴于設備的安全在過去已被破壞，并且隨著例如移動設備已成為開放的計算平臺，其很可能還會被進一步的破壞。自主確認基本不傳遞高級安全需求的信息；特別是，如果TS部分受損，則外部得不到任何關于其狀態(tài)的信息。因此，不能標記出受損的設備，這就意味著在被控制之前，還會繼續(xù)進行開發(fā)，而不會被注意并不會對其他相關方(例如網(wǎng)絡運營商)造成嚴重損害。根據(jù)失敗策略，可將自主確認實現(xiàn)為使驗證而對特定條件進行反應，所述特定條件為例如不允許特定功能，或關閉設備進行重啟。這避免了網(wǎng)絡連接，看起來由優(yōu)越性。但是，這同時對拒絕服務(DoS)攻擊又是一種媒介。設備在受損狀態(tài)時必須不連接到網(wǎng)絡，因此幾乎沒有機會恢復至安全狀態(tài)。遠程管理也很困難；特別是由于在軟件下載和安裝的過程中可能向受損設備發(fā)送數(shù)值(軟件、秘密)，因此可能會造成安全性的損失。因此，自主確認傾向于進行帶外維護。例如，TR軟件更新的失敗可能會導致在該設備狀態(tài)中不能進行網(wǎng)絡連接。
[0064]使用自主確認，證明數(shù)據(jù)的時新性是不能由其自身進行保證的。為了滿足這種安全屬性，每次系統(tǒng)狀態(tài)發(fā)生變化時，都需要自動進行自主確認。由于自主確認在操作期間，例如在網(wǎng)絡附屬期間，進行得并不頻繁，因此TS狀態(tài)可能會在TS操作期間發(fā)生重大變化，而確認器觀察不到。因此，攻擊者會利用該間隙，例如植入惡意軟件。自主確認非?？赡苁艿竭@類定時攻擊。
[0065]在遠程確認中，確認器直接根據(jù)其所接收的用于驗證的證據(jù)來評價TS的有效性。在這種情況下驗證是完全被動的，并且必須向確認器發(fā)送完整的SML。這種情況的模型是由認證啟動所進行的驗證和隨后的確認。所有策略判斷都位于確認器。
[0066]現(xiàn)有技術中用于確認的技術是遠程確認，特別是用于TCG遠程證明的遠程確認。在遠程證明中，由TCG可信平臺向外部確認器顯示SML和PCR、由證明標識密鑰(AIK)簽名的遠程證明的確認和驗證數(shù)據(jù)。該AIK是經(jīng)PCA證明的短時非對稱密鑰對，該PCA用作確認標識提供者。在遠程證明中提供的偽名并不是在所有情況下都夠用。TCG額外定義了根據(jù)零知識證明的直接匿名證明(DAA)。
[0067]由于遠程和自主確認是半自主確認所納入的多個選擇中的極端情況，遠程確認也有其不足。由遠程證明所表示的遠程確認，由于其對連接至網(wǎng)絡或服務的(中央)接入點施加了用于確認的完全計算負載，因此其在調(diào)節(jié)度和復雜度方面表現(xiàn)出了操作上的問題。特別是，對于類似個人電腦這種具有大量各種版本和結(jié)構(gòu)的軟件和硬件組件的平臺，確認SML的耗費很大。這同時還需要有巨大的TRV數(shù)據(jù)庫，例如RM，其與基礎結(jié)構(gòu)一起，來使相關方能夠定義所需的TS目標配置。相同的原因還會遠程確認對TS遠程管理(即配置的可控和確認改變)來講顯得不夠?qū)嶋H。此外，運行驗證期望進行遠程確認，否則只能向確認器顯示啟動后的狀態(tài)。SML會在確認時“消失”。因此，如果之后不立即進行確認，運行驗證就沒有意義，而確認需要非常頻繁地進行遠程確認。最終，由于所顯示的SML可能對TS幾乎是唯一的，因此復雜的開放TS的遠程確認只能向秘密性妥協(xié)，而不顧是否使用PCA。類似的經(jīng)濟上的原因是可能存在遠程證明所造成的歧視，即，由于擔心只有主要賣家最新版本的軟件才能進入TPV數(shù)據(jù)庫(例如RM數(shù)據(jù)庫)，因此使得其他程序的用戶轉(zhuǎn)而使用這些軟件版本，或放棄服務連接?？梢酝ㄟ^修正遠程證明方式來減少一些缺陷，例如基于語義或?qū)傩缘恼J證，其目的是展示組件特征而不是具體實施。
[0068]半自主確認是另一種在驗證期間評價TS有效性的過程，該評價是在該設備自身內(nèi)本地地進行，而不依賴于外部實體，且在驗證期間進行策略判斷。但在這種情況下，需要向確認器發(fā)送特定信息，下面稱為“確認消息”，例如是驗證結(jié)果和所需證據(jù)，該確認器可以根據(jù)來自TS的確認消息的內(nèi)容來進行判斷。必須對從TS至確認器的信令進行保護，以提供認證、完整性和如果需要的話，還有機密性。半自主確認的一種模型是安全啟動，之后向確認器發(fā)送關于事件結(jié)構(gòu)和TRV指示的信令。半自主確認在TS和確認器之間分配驗證和強制任務。特別是在安全啟動進程中，前者在加載組件時進行決定，而后者則根據(jù)所提供的狀態(tài)證據(jù)，在確認時強制TS所允許的關于交互的決定。
[0069]半自主確認可以提供優(yōu)于另兩種選擇的長處。其可能以驗證時所用的RM指示符的形式來更有效地傳輸確認信息。例如，當這種指示符表示一組具有相同功能和可信度(例如版本)的組件時，這種方法還可用于保護隱私。這與基于語義和屬性的認證類似，并且還可將半自主確認與上述遠程確認的改進方式相結(jié)合。在對確認器進行驗證過程中的強制執(zhí)行所帶來的相互作用還使得能夠?qū)S進行遠程管理。
[0070]在技術實現(xiàn)的過程中，可以使用修正來實現(xiàn)“對由于完整性驗證失敗而沒能成功獲得網(wǎng)絡連接許可的AR (接入請求者)進行隔離和修正的支持”。理論上，可如當前授權策略的定義，向AP提供所有最新的有關完整性的信息。其例子包括OS補丁、防病毒(AV)更新、固件升級和其他類似的軟件或固件更新。實現(xiàn)遠程管理的具體概念可能需要依賴能夠有效地表示和發(fā)送TRV信息(例如RM信息)的基礎結(jié)構(gòu)，如此處用于PVM的所述。
[0071]非常需要在此處強調(diào)RM證書在半自主確認中的角色。RM證書是由已經(jīng)直接評價或委托評價了相應TR的證明機構(gòu)所提供的。證明方法和實體可以是多樣的，并且涉及不同的操作可信度級別。這使得半自助確認器更加具有靈活性，其中所述半自助確認器獲得了關于TS更細的信息。如此所述，RIM證書被用作可支持對組件進行設備接通(on-device)確認的數(shù)據(jù)的示例。盡管在此描述的是基于RM證書的SAV方法，但是也可使用其他SAV形式。
[0072]對于資源受限的系統(tǒng)，半自主確認也是唯一可操作的確認選擇，這時因為對于資源受限系統(tǒng)來講:a)其缺乏進行自主確認所需的處理能力，和b)缺乏執(zhí)行遠程確認所需的眾多報告的存儲和/或通信能力。例如，在無線傳感器網(wǎng)絡的上下文中，傳感器節(jié)點同時受到這兩種限制。在這些情況下，一種方法是向傳感器發(fā)送存儲器探測代碼，該存儲器計算出靜態(tài)存儲內(nèi)容(代碼和參數(shù))的摘要值，從而生成可預測的結(jié)果，該結(jié)果被發(fā)回基站以用于確認。攻擊者顯然可以通過使用所存的原始存儲內(nèi)容生成正確結(jié)果來避開該“認證”。只要該攻擊是在傳感器本身上進行的，則該傳感器會不可避免地產(chǎn)生延遲，該延遲會由于隨機化、自修正探測路徑和混淆方法而加強。因此，如果傳感器應答中顯著的延遲超出了預定閾值，則傳感器失效。
[0073]在半自主確認中，在安全啟動期間內(nèi)部評價H(e)NB的有效性，而不依賴于外部實體，且在該評價期間進行策略決定，特別是根據(jù)各個組件的所測量的的完整性來做出關于加載/啟動哪些組件和不加載/啟動哪些組件的策略決定。在半自主確認中，向平臺確認實體(PVE)發(fā)送評價結(jié)果和所需證據(jù)，該平臺確認實體根據(jù)確認消息的內(nèi)容自己進行決定。應當對向PVE發(fā)送的信令進行保護，以提供認證、完整性和如果需要的話，還有時新性和機密性。半自主確認在H(e)NB和外部確認實體(例如PVE)之間分配完整性驗證和強制任務。特別是在安全啟動過程中，H(e)NB在組件加載/啟動時在本地進行決定，而PVE可根據(jù)所提供的狀態(tài)證據(jù)，在確認時強制進行關于H(e)NB所允許的交互的決定。根據(jù)PVE的決定的結(jié)果，或者授予對網(wǎng)絡和服務的全接入，或者可以提供更多受限條件，例如隔離網(wǎng)絡接入和強制配置變化。
[0074]稱為可信環(huán)境(TrE)的可信實體對半自主確認非常重要。用于半自主確認的過程可以不同。在一個實施例中，H (e) NB可按圖3所示的流程圖300執(zhí)行對H (e) NB完整性的半自主確認。在執(zhí)行設備認證過程之前，H(e)NB的TrE首先對H(e) NB的特定的預先指定組件(例如啟動代碼)的完整性進行檢查(305)。之后，至少暫時地記錄或存儲該完整性檢查結(jié)果(310 )。這一步可在H (e) NB上電后，在認證的第一時刻(例如，為了建立安全回程鏈接)之前，由TrE自身自主啟動?？蓪⑵湔J為是“安全啟動”。TrE通過僅將注冊組件加載和/或啟動至完整性證實狀態(tài)，來確保H(e)NB的完整性。如果需要重新評價所建立的信任(例如由于在之前成功的網(wǎng)絡連接會話后H(e)NB的配置發(fā)生了變化)，則可以以兩種方式來對這種完整性證實啟動狀態(tài)進行檢查。在第一種情況中，可由TrE自身自發(fā)地啟動該檢查。另一種可由來自網(wǎng)絡(例如，安全網(wǎng)關(SeGff)或平臺確認實體(PVE))的請求啟動，該請求要求TrE之后完成。
[0075]之后TrE可檢查H(e)NB的剩余部分的預定部分是否已經(jīng)達到安全啟動狀態(tài)(315)。該進一步檢查可以由TrE自身來啟動，或由H(e)NB中的度量組件來啟動，該度量組件在TrE外部，但由TrE進行完整性保護(320)。在這種后階段檢查中，只要對度量組件可行，則當加載或啟動、或在其他預定運行事件時，就檢查H(e)NB的剩余部分的其他組件、配置或參數(shù)的完整性。至少暫時地記錄或存儲安全啟動檢查結(jié)果(325)。優(yōu)選地，采用由TrE或由其他方式的完整性保護(例如密鑰哈什值)所提供的受保護的存儲器來記錄安全啟動檢查結(jié)果以及完整性檢查結(jié)果。
[0076]在進一步的方式中，除了在已有PVE協(xié)議中所提供的時新性之外，可對結(jié)果(即單獨的測量結(jié)果)額外加上安全時間戳以便為測量本身提供時新性和重放保護?？梢酝ㄟ^在執(zhí)行哈什功能前加上時間戳的值并之后將該結(jié)果存儲在受保護的寄存器(例如PCR)中，來將時間戳的值包括在測量值中，從而實現(xiàn)這種時新性信息。
[0077]之后TrE對檢查結(jié)果進行處理，以從該檢查結(jié)果中生成要發(fā)送至PVE的確認消息(330)。一旦接收到的該消息，PVE便使用該消息來評價H(e)NB的信任狀態(tài)(335)。在一個處理實施方式中，TrE使用簽名密鑰簽發(fā)聲明，聲明H(e)NB已通過自主確認檢查，該簽名密鑰受TrE保護并從而保護了該聲明的完整性。該聲明還可包括可供PVE用于對TrE對H (e)NB預定組件所執(zhí)行的完整性檢查的狀態(tài)或結(jié)果進行評價的證據(jù)，還可包括關于自主確認檢查和之后的設備認證過程之間的任何綁定的證據(jù)。TrE也可對該聲明加上時間戳以確保其時新性。這種簽名的聲明證明由TrE從重排序的數(shù)據(jù)或結(jié)果所獲得并發(fā)送至PVE的消息是在安全啟動進程后來自H(e)NB的TrE的消息。對于簽名的驗證，應當將確認結(jié)合至設備認證，或使用單獨的TrE標識。由于認為H(e)NB啟動配置的TrE自主檢查的結(jié)果是可信的，因此該簽名通過增加某些可追溯性而增強了純自主確認檢查的安全性。
[0078]TrE通過SeGW將所述簽名的聲明發(fā)送至PVE，之后PVE可使用該來自H (e) NB的簽名聲明，并決定是否允許H (e) NB繼續(xù)進行認證(340)。PVE可以以多種方式來使用簽名的聲明中的信息。在一個實施方式中，PVE可以將TrE自身的完整性與單獨的靜態(tài)配置進行核對，在核對失敗時拒絕接入連接。在另一實施方式中，可將PVE配置為對接入控制做出更細的判斷。特別是，這表明根據(jù)TrE內(nèi)部或外部單個/多個組件的存在/不存在和完整性，可拒絕接入。而在另一實施方式中，根據(jù)確認聲明中所包含的指示，可將PVE配置為從可信第三方獲得關于H(e)NB組件的完整性和安全性屬性的信息。這表明可將PVE配置為能夠獲取有關設備上的組件的參考值(即有效數(shù)據(jù))的信息。之后，通過將確認數(shù)據(jù)與從設備所接收的數(shù)據(jù)進行比較的過程，而得出有關組件實際完整性的信息。PVE不會直接從TTP獲取關于組件完整性的聲明，而僅從可以比較報告值的TRV獲得。而在另一個實施方式中，可將PVE配置為在允許接入前，進行配置變化。這種修正過程可包括強行的軟件更新。
[0079]如上所述，TrE能夠生成可信且精確的時間戳，并可使用在其中或受其保護的密鑰進行簽名。在一個實施方式中，當TRE執(zhí)行本地自主設備完整性檢查時，外部確認器可驗證“時間”。這表示，在第一次或最后一次測量時，獲得時間戳。還可表示，當在PVE開始運行協(xié)議時，使用時間戳。還可表示，在每次測量中都包含時間戳。所期望的“時間粒度”可指示使用哪種方式。在另一實施方式中，可將TrE配置為插入兩個時間戳，一個在TRE執(zhí)行本地自主設備完整性檢查之前獲得，一個則在所述完整性檢查之后獲得。這種時間戳有效地“鎖定” 了本地自主設備完整性檢查實際發(fā)生的時間范圍，而通過在發(fā)送表示本地自主完整性檢查結(jié)果或過程的數(shù)據(jù)的同時發(fā)送這種時間戳，TrE可以使外部確認器不僅能評價設備的完整性狀態(tài)，還能得知關于H(e)NB的完整性是在何時和怎樣由TrE進行本地測量和驗證的時間歷史。這樣，根據(jù)時間I)獲得該聲明的時間(由第二個，即后一個時間戳所指示)，以及當接收到該帶有時間戳的確認消息時，確認器自身的時間標記，和2)進行本地自主完整性檢查的時間(鎖定在兩個時間戳所指示的兩個時間之間)，確認器便能夠使用其自身的“時間窗”，來判斷怎樣對其從TrE所接收的涉及設備完整性狀態(tài)的簽名聲明進行處理。
[0080]可以通過使用此處所述的PVM方法、裝置和結(jié)構(gòu),來使用PVM,從而實現(xiàn)此處所述的策略和方法。PVM通常在活動實體間使用最大任務分隔。該方法清楚地定義了在平臺確認和管理過程中所涉及的每個實體的活動區(qū)域。PVM方法的優(yōu)點在于:1)可以分別為每個實體實現(xiàn)最優(yōu)化處理；2)具有PVM的設備可不同時運行(有限制)；3)目前對于所涉及的網(wǎng)絡實體來講，PVM方法可無國家區(qū)別地操作；4)可單獨對實體進行維護和管理；和5)更容易進行備份和故障恢復。特別是，對于有效地執(zhí)行設備的確認和遠程管理來講，性能和可用性是非常重要的。在具體情況中，會存在設備組件大量更新的事件，或大量設備變更所選的歸屬運營商(SHO)?？蓪VM結(jié)構(gòu)配置為由單個運營商(通常為SH0)對一個設備執(zhí)行確認和管理。作為例外，如此處所述，PVM的特殊形式可能會對漫游接入和運營商變化產(chǎn)生影響。
[0081]部分依賴于根據(jù)可信計算的安全技術，當設備首次嘗試連接至通信網(wǎng)及之后對設備完整性進行監(jiān)視時，PVM提供了系統(tǒng)的方法來對設備進行確認和管理。PVM可提供:1)在網(wǎng)絡連接前確認設備；2)以無線方式(OtA)管理設備配置；3)通過在加載/啟動組件時檢查TRV (例如RM)來實現(xiàn)安全啟動；和4)為配置改變而在設備上安裝新TRV (例如，RM)——TRV 獲取(ingestion)。
[0082]在此處所述的PVM的示例實施方式中，對其所確認的設備和網(wǎng)絡進行以下技術上的假設和預處理。對于網(wǎng)絡，首先假設所有實體都作為相同核心網(wǎng)(CN)的一部分由同一個的移動網(wǎng)絡運營商(MNO)來進行操作。因此，在這些實體之間不會因為要建立信道和實際通信而進行額外安全保護(例如，相互認證、消息的完整性保護、加密)。在需要時，如果為特別用途，還會描述額外的安全特征。不管怎樣，PVM的適用范圍可擴展至這些實例，這是因為該PVM方法可由MNO的CN以外的實體，甚至是由MNO以外的另一方所管理的實體進行使用。
[0083]對于設備，設備可有多種風格和多個名稱。PVM可用于演進型通用移動電信系統(tǒng)(UMTS)陸地無線電接入網(wǎng)絡(E-UTRAN)的H(e)NB和機器對機器(M2M)設備，還可用于多種其他滿足特定條件的網(wǎng)絡設備。這些條件基本與可信系統(tǒng)(TS)的相同。當使用PVM時，各個設備被配置為使用PVM方法，從而成為PVM設備。
[0084]作為確認過程的前提條件，確認需要有標識，設備可對該標識進行認證。需要該認證來保護PVM基礎結(jié)構(gòu)不受到特定假冒設備的攻擊，并且不能把該認證與設備向CN的認證(該認證在確認后，或與確認過程一起進行)相混淆。這表明，只有在PVM認證了設備標識后，該設備才被PVM允許，從而避免了不能執(zhí)行PVM協(xié)議的未知設備對PVM系統(tǒng)施加例如DoS攻擊。
[0085]為了 PVM的目的，設備標識Dev_ID是設備中與可信環(huán)境(TrE)、通用集成電路卡(UICC)或智能卡、或是設備本身(例如H(e)NB)相綁定的標識，都沒有關系。假設該設備能夠安全地管理與Dev_ID有關的認證證書，從而能夠?qū)ev_ID進行認證。該Dev_ID可以是正式域名(FQDN)、統(tǒng)一資源標識符(URI)、統(tǒng)一資源定位符(URI)、統(tǒng)一資源名(URN)、媒介接入控制(MAC)地址(例如擴展的唯一標識符(ΕΠ-48)，EU1-64)、IPv4或IPv6地址、包含子網(wǎng)地址的IPv6主機標識符(例如64LSBs)、國際移動設備標識aMEI)、MEISV (例如gsm/umts)、電子序列號(ESN)、移動設備標識符(MEID)(例如cdma)、國際移動用戶標識(MSI)、臨時移動用戶標識(TMSI)(當由于用戶和設備間1:1的映射而可由用戶標識出設備時)、IMS用戶id (例如IP多媒體個人標識(IMPI)或IMS用戶公共標識(IMPU))、移動站集成服務數(shù)字網(wǎng)(MSISDN)，或任何其他字母數(shù)字形式或機器可讀格式的標識符，該標識符能夠?qū)缑總€運營商實現(xiàn)唯一的(例如全球或至少域內(nèi)唯一的)可靠和明確的對單個設備進行標識。
[0086]該設備可具有值得信任的TrE。可在安全啟動進程中，從不可變信任根(RoT)構(gòu)建設備中的TrE。該TrE提供了安全的執(zhí)行環(huán)境和其他基本的受保護的性能。該TrE可以是受管理的組件，例如可變的，這樣只有RoT保持不變。
[0087]從可信計算的角度來看，可將TrE看做TCB，該TCB由一些安全執(zhí)行環(huán)境和特定受保護接口所擴展的TPM或MTM構(gòu)建而得。作為從TPM或MTM所構(gòu)建的TCB的TrE屬于非限制性的示例，其他信任實施方式同樣適用。
[0088]對于PVM，TrE提供了能夠無條件可信的TCB。但是，作為傳統(tǒng)可信計算的變化方式，由TrE所構(gòu)建的TCB在PVM中不是不變的。這是因為在PVM中，TrE及其在設備中的周圍環(huán)境都是不同的。將關于這兩部分專門的不同的信息發(fā)送至基礎結(jié)構(gòu)，并根據(jù)不同策略使用該信息對其進行確認和管理。TrE是PVM基礎結(jié)構(gòu)最主要的通信方，并被認為能正確執(zhí)行與PVM有關的任務。
[0089]H (e) NB和TrE可以在啟動時，在連接至核心網(wǎng)之前或H (e) NB連接至H (e) NB管理系統(tǒng)(HMS)之前，執(zhí)行設備完整性檢查。該設備完整性檢查可以基于一個或多個可信參考值和TrE?？梢砸骉rE每次都安全地存儲所有可信參考值?？梢骉rE安全啟動。還可要求TrE支持單組件或多組件完整性檢查。
[0090]在單組件完整性檢查中，可要求TrE為作為單組件的設備的可信操作加載所需的完全代碼。在啟動該組件前，可要求TrE來執(zhí)行完整性檢查(例如通過將該組件的加密哈什測量與所存儲的可信參考值相比較)以確定該組件的完整性。如果該單組件通過了其完整性檢查，則可啟動該組件。如果完整性檢查失敗，則不能啟動該組件。
[0091]在多組件完整性檢查中，可根據(jù)設備功能而對用于該設備可信操作所需的設備完全代碼庫進行分割，并按順序放入多個組件中。可要求TrE按順序加載每個組件，并在啟動任何一個組件前，可要求TrE執(zhí)行完整性檢查(例如通過將該組件的加密哈什測量與所存儲的可信參考值相比較)以確定該組件的完整性來。如果單個組件通過了其完整性檢查，則可啟動該組件，且TrE可繼續(xù)對下一個組件進行完整性檢查。如果任何一個組件的完整性檢查失敗，則不能啟動該組件，但TrE可以繼續(xù)檢查下一個組件的完整性。
[0092]對于組件完整性檢查中的每一種，可以要求TrE從安全存儲器中查找相應的可信參考值并將完整性測量與可信參考值進行比較，其中該安全存儲器對TRV提供完整性保護。該安全存儲器包括但不限于TrE的受保護存儲器。如果該設備可信操作所需的所有組件都經(jīng)過驗證了，則該設備的完整性就經(jīng)過驗證了。
[0093]對于安全啟動，通過構(gòu)建信任鏈，安全啟動進程在幾個步驟中從RoT進入全功能狀態(tài)。圖4表示了四階段安全啟動方法400的示例流程圖。在階段1，在安全啟動中從RoT405構(gòu)建TrE410。所有加載或啟動的組件都要經(jīng)過驗證，并且只有通過了驗證的組件才能加載和啟動。只有階段I成功時，才控制TrE410執(zhí)行安全啟動的階段2。
[0094]在階段2中，TrE410進一步對執(zhí)行PVM所必需的組件進行驗證、加載和啟動。例如，這可以包括通信和協(xié)議棧及無線電接入網(wǎng)(RAN)通信模塊。所有加載和啟動的組件都需要經(jīng)過驗證，且只有通過驗證的組件才能加載和啟動。
[0095]只有階段2成功時，才啟動安全啟動的階段3。在階段3a中，TrE410進一步驗證、加載和啟動組件。只有通過了驗證的組件才能加載和啟動。在階段3b中，TrE進一步測量和加載組件。
[0096]假定對組件進行驗證是通過獲得其測量值(415所示)，并將該測量值與存儲在R頂存儲器420中的RM進行比較(425所示)而完成的。如圖所示，圖4包含RM存儲器作為示例或?qū)嵤┓绞?。但是，如此處所述，RIM和RIM證書只是結(jié)構(gòu)數(shù)據(jù)的一個示例方式，也可使用其他方式的結(jié)構(gòu)數(shù)據(jù)。此處的描述允許使用RM以外的方式和實施方式的結(jié)構(gòu)確認數(shù)據(jù)。認為所有階段中的加載順序是由本地可用列表所管理的。假定3a和3b中組件之間的區(qū)別是由本地可用策略所管理的?？蛇x地，可將加載和驗證合并在一個階段中。
[0097]在圖4中，使用術語“TrE”來描述包含了 PVM功能所需的最少功能的實體，該實體包括所有安全啟動所需的功能，例如測量415、RM存儲420、將RM與實際測量進行比較的驗證引擎425。顯然，這里對TrE的描述是為了簡潔，而TrE可以更復雜，并包括其他組件，例如密鑰生成器或隨機數(shù)生成器(RNG)。所示的TrE可以包括實現(xiàn)安全啟動所需的所有功能?？稍赥rE外部存儲RM，但由TrE保護其完整性和(可選地)機密性。用于測量和驗證的引擎也可作為TrE的外部組件來實現(xiàn)。之后TrE可確保這些組件的完整性，并提供安全操作環(huán)境，使得這些組件不被修改。
[0098]在階段3中可能會因策略不同而有更精細的粒度。例如，如果組件的驗證失敗或RM不可用，則可將該組件加載至沙箱(sandbox)環(huán)境中?？蓪㈦A段3a和3b之間的區(qū)別與移動電話工作組(MPWG)參考結(jié)構(gòu)的安全啟動中的可信服務和測量服務之間的區(qū)別進行類比。[0099]可為“用戶空間”中沒有通過驗證的組件增加第四階段。
[0100]在階段2中單個或多個組件(通信模塊或其他類似模塊)的失敗并不表明該設備不能進行通信。可將該階段理解為屬于特定種類的組件類型。只要加載了階段2的最基本的組件，設備就能將其狀態(tài)和失敗組件發(fā)送給PVM系統(tǒng)。這樣的設計使得如果一些組件的內(nèi)部驗證失敗，該設備也能執(zhí)行PVM (以及修正過程)，而不需重啟。
[0101]在另一實施方式中，當在安全啟動期間檢測到攻擊時，可使用回退代碼庫(FBC)來使設備執(zhí)行PVM。該設備會在檢測到攻擊時使用FBC進行重啟，之后進入能修正設備的預定狀態(tài)。
[0102]在安全啟動期間，TrE記錄并保護以下信息不受到篡改:1)所加載的組件的列表(Clist) ；2)所加載的組件的參數(shù)；3)與一些或全部組件相關的測量值；和4)對一些或全部測量值的結(jié)果(例如平臺狀態(tài))進行的唯一標記(例如加密)的驗證數(shù)據(jù)。根據(jù)PVM所用的確認方法，一些或全部記錄是可選的。例如，自主確認(AuV)都不使用。
[0103]PVM可使用以下術語。術語“驗證”可用于表示安全啟動期間設備組件內(nèi)部的驗證，而術語“確認”用于表示由外部實體進行的設備檢查過程。從而避免了引入“內(nèi)部”確認和“外部”確認的概念。驗證是按通常意義的加密檢查或數(shù)據(jù)匹配來進行的，此處明確指出以避免產(chǎn)生混淆。
[0104]PVM至少使用安全網(wǎng)關(SeGW)、平臺確認實體(PVE)和設備管理服務(DMS)。由于由設備中的TrE來執(zhí)行設備內(nèi)部的確認重要任務，因此通常由該TrE與其他實體進行通信。雖然此處通信所需的其它設備組件(例如網(wǎng)絡接口)并不一定是TrE的集成部分，但是TrE應當能夠評價這些組件的完整性以確保端對端的安全。
[0105]對任務的嚴格分隔要求每個實體都限制在其核心任務之內(nèi)。例如，SeGW在(不)可信設備與MNO的CN之間建立安全接口。其用作MNO的CN的屏障和網(wǎng)絡接入控制及強制實例。其同時還執(zhí)行作為屏障所需的所有安全相關功能，包括認證、對與設備的通信的加密/解密、安全性關聯(lián)和會話建立。可將SeGW用作能夠在MNO的CN與外部世界(例如外部設備)之間建立邊界的網(wǎng)絡實體的實例。也能不用SeGW，而使用PVM方法來進行設備確認。為此需要使用安全連接將設備直接連接至DMS，該安全連接例如是傳輸層安全性(TLS)。
[0106]對于PVE，其用作CN中的確認實體，并執(zhí)行完整性確認。其接收完整性驗證數(shù)據(jù)，并檢查所報告的值是否已知并良好。其向CN中的其他實體發(fā)布關于設備完整性的聲明。
[0107]對于DMS，其用作用于管理設備組件的中心實體，包括軟件更新、配置變化、OTA管理和失敗模式修正。DMS通過基于平臺確認而實現(xiàn)該功能，而與HMS的增強型版本相類似。
[0108]除上述實體以外，PVM還包括RM管理器(RIMman)。RIMman執(zhí)行以下功能，包括:為在確認中進行比較而管理和提供可信參考數(shù)據(jù)和TRV。其還管理證書，特別是獲得外部RIM證書、驗證RM證書、生成(運營商專用的)RIM證書，并通過例如撤銷、時間限制和信任關系等手段來檢查證書有效性。也就是說，RM管理器是唯一一被授權管理確認數(shù)據(jù)庫(V_DB)的實體。該V_DB和RIMman受到CN組件保護。向V_DB的寫入僅受到RIMman的限制，因此PVE不能寫入V_DB。RIMman對安全有特殊的重要意義，因為其管理著PVM所需的(SHO-CN)外部信任關系。如此所述，RIMman是一種實施方式，其可擴展為包含其他實施方式的用于(分級)結(jié)構(gòu)數(shù)據(jù)的參考值和證明參考值的管理器。
[0109]PVM還包括配置策略管理器(CPman)，用于執(zhí)行設備配置的管理和提供。其還管理策略，特別是外部(例如從可信第三方(TTP)獲得的)配置和策略，和生成(運營商專用的)目
標設備配置和策略。也就是說，CPman是唯--個被授權管理配置策略數(shù)據(jù)庫C_DB的實體。
該CPman對安全有特殊的重要意義，因為其管理PVM所需的(SHO-CN)外部信任關系。
[0110]圖5A和5B示出了 PVM的最小實體集合、其相互關系和接口的示例。還示出了其它實體，例如認證授權和計費(AAA)服務器和無線發(fā)射/接收單元(WTRU)及其接口。
[0111]圖5A的PVM結(jié)構(gòu)或系統(tǒng)500包括設備505，該設備505具有TrE510。WTRU512可以通過1-ue接口 514與設備505進行通信。設備505通過I_h接口 515與SeGW520進行通信。通常，設備505與SeGW520之間的接口 I_h515不需要保護，可以采取特別措施來保護該信道的真實性、完整性和可選的機密性?？梢允褂肐_h515來建立設備505與SeGW520之間的鏈路(從而建立與CN之間的鏈路)。例如，SeGW520可以通過I_aaa接口 575來與AAA服務器進行通信。運營商可以采用適當措施來保證接口的安全。
[0112]確認期間，SeGW520可以使用1-pve接口 522來聯(lián)系PVE524。PVE524可以使用1-pve接口 522來將確認結(jié)果發(fā)送給SeGW520?？墒褂?-dms接口 530來進行在DMS535和SeGW520之間的涉及設備配置的通信。PVE524可使用I_pd接口 532來與DMS535進行通信，反之亦然?？稍谠O備管理過程期間使用接口 I_pd532，來用于例如設備軟件更新和配置變化。
[0113]PVE520可使用接口 I_v526和I_d538來從V_DB540讀取RM，而DMS535可使用上述接口從C_DB550讀取所允許的配置。在例如V_DB540中發(fā)生RM丟失的情況下，PVE520可使用接口 I_r528和1-c534來與RIMman560進行通信，而DMS535則可使用上述接口與CPman570 進行通信。RIMman560 和 CPman570 可使用接口 I_rdb562 和 I_cdb572 來分別讀取、寫入和管理數(shù)據(jù)庫V_DB540的確認和配置策略數(shù)據(jù)庫C_DB550。
[0114]圖5B示出了 PVM582，其中設備505可直接連接至DMS535。例如，是在回退模式的情況下，設備505在該模式中不能與SeGW執(zhí)行安全性協(xié)議。在這種情況下，DMS535可通過接口 1-dms_d584作為設備505的第一連接點，并通過接口 I_pve586和I_pd588與PVE524進行通信以執(zhí)行確認，或者至少獲知在安全啟動期間是哪些組件失敗了。DMS535可在收到該信息后立即進行修正。
[0115]通常，各個組件，例如包括TrE510的設備505、SeGW520、PVE524和DMS535都優(yōu)選地被配置為在處于活動狀態(tài)的實體之間使用PVM最大類型的任務分隔的方法。如下詳細描述的，這可通過使用PVM令牌在各個實體之間傳遞特定信息來實現(xiàn)。
[0116]如此處所述，PVM可使用各種版本的確認。此處所述的是與PVM —起操作的半自主確認(SAV)。在本實施方式中，設備包含TrE和RoT，并且能夠進行安全啟動。該設備具有RM，該RM能夠?qū)崿F(xiàn)對TrE組件和TrE外部組件進行本地確認。在本實施方式中，該設備可以是H(e)NB。如此所述，RIM只是結(jié)構(gòu)數(shù)據(jù)的一種形式和示例，其在此用作非限制性的示例。
[0117]該設備可通過3個階段執(zhí)行安全啟動，確保在并且只在所要加載的組件的本地確認成功時才加載每個組件。在階段I中，通過依賴于RoT的安全啟來加載TrE。在階段2中，加載TrE外部的所有執(zhí)行基本通信所需的組件。在階段3中，加載所有剩余的設備組件。
[0118]之后，該設備可與SeGW開始進行網(wǎng)絡認證。在認證期間，發(fā)送以下數(shù)據(jù)中的一個或多個:Dev_ID ;設備的安全策略；關于在安全啟動期間已由TrE檢查了完整性的設備模塊的信息；硬件/軟件構(gòu)建版本號；設備制造商；模型和版本號；設備和TrE的證明信息；以及TrE能力和屬性。
[0119]可使用不同選擇來將該數(shù)據(jù)發(fā)送至PVE(通過SeGW)?？稍诨ヂ?lián)網(wǎng)密鑰交換版本2(IKEv2)認證協(xié)議的通知字段發(fā)送該數(shù)據(jù)，并在之后由SeGW轉(zhuǎn)發(fā)給PVE。之后PVE對所接收的信息進行檢查。PVE檢查Dev_ID是否列在黑名單中，如果是，則拒絕接入。其檢查安全策略是否與該設備所需的策略不匹配。如果不匹配，則可執(zhí)行修正步驟。PVE可檢查是否加載了未標記的/不想要的模塊和組件。
[0120]在上述每個檢查中，如果得到表明設備TS的驗證失敗的肯定回答，則PVE可拒絕或限制(例如，隔離受限的使用或資源)對該設備進行網(wǎng)絡連接。PVE向SeGW發(fā)送關于對該設備的有效性和可信度的決定的消息。SeGW根據(jù)該消息進行操作。
[0121]在第一種方式中，將數(shù)據(jù)存儲在可信第三方(TTP)，由設備發(fā)送對TTP的指針，PVE可從其中獲得所需信息?？稍贗KEv2的通知負載中發(fā)送該指針。
[0122]在第二種方式中，只要所有數(shù)據(jù)是靜態(tài)的，就可在認證期間將其包括在(可能是增強的)設備證書中。組件的任何更新都會使測量值產(chǎn)生變化，因此，安全啟動中所用的RM會需要新的設備證書。
[0123]此處所述的實施方式是與PVM進行操作的遠程確認或半自主確認(F-SAV)。在階段I中，可在安全啟動期間從RoT構(gòu)建TrE。TrE的所有組件都可以是經(jīng)完整性驗證的，并在驗證成功時加載。在階段2中，TrE可對設備剩余部分的預定部分的完整性進行驗證，并加載。進行完整性檢查的代碼可包括例如基礎OS、與SeGW的基礎通信和安排(format)執(zhí)行PVM報告消息的代碼?？蓪y量值存儲在TrE的安全存儲器中。
[0124]如果階段I或階段2的檢查失敗，則TrE可停止進行認證。如果階段I和階段I都成功了，則可以進行階段3。例如，可對例如包括無線電接入碼的設備剩余模塊代碼進行完整性檢查，但可不加載。可以準備確認數(shù)據(jù)，并在合適的通信協(xié)議中將確認數(shù)據(jù)發(fā)送至SeGW。該數(shù)據(jù)可由例如TrE所存的密鑰進行簽名，以提供該數(shù)據(jù)的真實性和完整性。該數(shù)據(jù)可包括完整性檢查失敗的階段3模塊的列表。
[0125]可使用IKEv2AUTH_REQ消息的通知負載來發(fā)送該數(shù)據(jù)。除由IKE安全關聯(lián)所提供的對整個消息的保護以外，還可由TrE的簽名密鑰對通知負載中的數(shù)據(jù)進行簽名，以提供該數(shù)據(jù)的真實性和完整性。該通知負載可包括完整性檢查失敗的階段3模塊的列表。可以使用合適的IKEv2消息的任何其他合適的負載或字段、或除IKEv2協(xié)議以外任何合適的協(xié)議(例如是TLS、TR069、OMA-DM、HTTP、HTTPS或其他類似協(xié)議)消息的其他合適的負載或字段來發(fā)送該確認數(shù)據(jù)。
[0126]SeGW可將數(shù)據(jù)轉(zhuǎn)發(fā)至PVE進行判斷。認證過程可繼續(xù)進行，但是對網(wǎng)絡連接授權的決定可一直等到PVE已經(jīng)檢查了確認消息，并且做出或獲得關于被報告為確認測試失敗的模塊的基于網(wǎng)絡的策略決定。
[0127]在第三種方式中，與測量和執(zhí)行所述代碼不同，可以在不加載所述代碼的情況下加載所述代碼的測量和完整性檢查。SeGW可將該確認消息轉(zhuǎn)發(fā)至PVE，PVE可對所接收的列表進行確認。當設備從PVE接收到成功確認的結(jié)果時，就可以加載剩余的階段3模塊。
[0128]測量完整性和等待PVE決定是否執(zhí)行代碼的過程可以包括假設一旦代碼經(jīng)過測量就不再發(fā)生變化且如果PVE對其授權則可執(zhí)行該代碼。因此，需要具有安全存儲器，用于階段3中的所有組件代碼。另外，執(zhí)行環(huán)境可支持授權執(zhí)行，該授權執(zhí)行允許先加載代碼，在授權后再執(zhí)行該代碼?？赡軙虞d大量代碼，因此安全存儲器和執(zhí)行環(huán)境應當具有足夠大小。
[0129]F-SAV可向CN提供靈活性以獲知在“本地完整性檢查”中的實際情況。設備可發(fā)送關于階段I和2中代碼通過/失敗的指示，以及可選的，如果存在失敗模塊的話，還可發(fā)送失敗模塊的列表。F-SAV可對設備安全屬性和確認測量提供更細的粒度和更清楚地認識，可對受攻擊的設備提供更快更好的檢測，可為受攻擊的設備支持由網(wǎng)絡發(fā)起的修正，并且可在設備安全管理中為運營商提供靈活性。
[0130]TrE也可以在消息中加入時間戳以確保時新性。時間戳的替代做法是由網(wǎng)絡提供現(xiàn)時(nonce)，TrE在網(wǎng)絡接入?yún)f(xié)議啟動后，將該現(xiàn)時合并至前述消息中。這也是將設備認證與確認進行綁定的特征。
[0131]認證失敗修正可以是在例如階段I或階段2的完整性檢查首次失敗后激活回退模式，從而使設備具備足夠的功能性來連接至SeGW，以向其通知失敗。這之后會觸發(fā)操作和維護(OAM)過程，以允許設備軟件根據(jù)診斷進行更新。該回退模式需要具有足夠的功能性，以在TrE的監(jiān)控下，以安全的方式實現(xiàn)代碼的完全重建。
[0132]在第一種方式中，可在IKEv2AUTH_Request的通知字段中發(fā)送測量消息數(shù)據(jù)(與設備證明一起)。在第二種方式中，可在啟動基于IKEv2的設備認證之前，由適當?shù)陌踩珔f(xié)議來發(fā)送該測量消息數(shù)據(jù)。在第三種方式中，如果階段I或2的任何部分的檢查失敗，且如果失敗的模塊是對設備基本功能不重要的輔助功能，則可使設備繼續(xù)進行/附屬，而不加載這些模塊。同時，可安排進行一些OAM過程以更新設備軟件。
[0133]此處所述是對所有相關實體中的功能的高度概括。描述了 H(e)NB設備的系統(tǒng)結(jié)構(gòu)，在這種結(jié)構(gòu)中確認和遠程管理起著重要的作用。所述方法可直接用于H(e)NB網(wǎng)絡結(jié)構(gòu)中的實體。通過使用更通用的方法，以及根據(jù)任務分隔的角色定義，此處用于平臺確認和管理的方法可以很容易地用于或擴展至其他網(wǎng)絡連接設備。如果實體根據(jù)其功能進行映射，則可以類似的方式在其他環(huán)境(例如M2M)中實現(xiàn)。
[0134]在此處描述PVM功能的實施方式中，使用了 SAV。SAV能夠保護CN完全避免免遭惡意設備的攻擊。在SAV中，可由SeGW有效地建立隔離網(wǎng)絡。由于只接收限制在其任務之內(nèi)的數(shù)據(jù)，且只通過與SeGW的或由SeGW所建立的安全連接進行接收，因此對PVE和DSM沒有直接來自設備的攻擊。執(zhí)行PVM中的確認過程不需要在設備與CN的任何實體之間直接通信。只有在使用SAV的確認成功后，才允許對CN進行連接。這就確保了只有在證實安全狀態(tài)的設備才能與CN中的實體通信。
[0135]圖6A、6B和6C表示了使用PVM基礎結(jié)構(gòu)的SAV確認方法的示例。PVM基礎結(jié)構(gòu)包括此處所述的實體，包括TrE605、SeGW607、PVE609、DMS611、V_DB613和C_DB615。在相互認
證后(620), TrE605收集以下數(shù)據(jù)中的一些或全部:設備信息-例如Dev_ID、制造商、設
備能力(包括但不限于通信能力(例如支持的數(shù)據(jù)速率)、發(fā)送功率等級、信令特征和其他能
力)、TrE 能力和屬性(包括 RoT) ；TrE 信息(TrE_infomation, TrE_info)-包括 ID、證明
信息、制造商、構(gòu)建版本和模型、構(gòu)成、序列號；驗證數(shù)據(jù)一包括平臺配置寄存器(PCR)值；驗證綁定一例如PCR值上的簽名；組件指示符(Clnd)-組件Clist有序列表，還可包括組件參數(shù)；時間戳(可信或不可信)(622)。從TrE605發(fā)送至SeGW607的確認消息/數(shù)據(jù)可以包括上述日期(624)。
[0136]SeGW607將所接收的時間戳與本地時間進行檢查/比較，以檢測變化(626)。如果所報告的時間戳與本地時間不一致，則SeGW根據(jù)所報告的時間戳的屬性來進行操作。如果設備的時間戳是可信時間戳，并且出現(xiàn)了變化，則SeGW6070應當觸發(fā)對TrE及其可信時間源的再次確認。在不可信時間戳的情況下，SeGW607將其自身的可信時間戳添加在消息上。如果設備不能提供可信時間戳，則可由SeGW607添加可信時間戳，以提供對重放攻擊的防護。
[0137]當接收到該消息時，SeGW607可檢查是否存在驗證綁定(628)。這確保了驗證數(shù)據(jù)的真實性。之后，SeGW607創(chuàng)建PVM令牌(T_PVM) (630)，并在發(fā)送前向該T-PVM添加時間戳，以確保其時新性，并防止異步消息流(632)。
[0138]SeGW607將T_PVM轉(zhuǎn)發(fā)至PVE609 (634)，該PVE609反過來使用TrE信息查詢V_DB613(636)。如果向PVE609返回不可信的判斷(638)，則PVE向T_PVM施加時間戳(640)，并將其轉(zhuǎn)發(fā)至SeGW607 (642)。之后，SeGW607停止設備認證，阻止了設備附屬到網(wǎng)絡，并向TrE605發(fā)出警報(644)。
[0139]如果向PVE609返回可信判斷(646)，則PVE使用Dev_ID查詢C_DB(648)，該C_DB隨即向PVE609返回配置策略(650)。PVE609評價該策略配置(652)。
[0140]如果PVE609判斷該配置不可信(654)，則PVE609修改T_PVM并添加時間戳(656 )。之后，PVE609將該T_PVM轉(zhuǎn)發(fā)至SeGW607 (658)，該SeGW隨即停止設備認證，阻止設備附屬到網(wǎng)絡，并向TrE605發(fā)出警報(660)。
[0141]如果PVE609判斷該配置可信，并且允許該配置(662)，則PVE609從V-DB613中取回(retrieve)用于Clist或C_List中所有項的RM(664)。PVE609從RM中重新計算出正確的驗證數(shù)據(jù)，并將所計算的驗證數(shù)據(jù)與所報告的驗證數(shù)據(jù)進行比較(668 )。之后，PVE609修改T_PVM，并施加時間戳(670)。之后PVE609將該T_PVM轉(zhuǎn)發(fā)至SeGW607(672)。SeGW607在該V_PVM中檢查(或從該T_PVM中獲得)PVE確認結(jié)果(674)。SeGW607將對設備認證是拒絕還是同意發(fā)送到TrE605(676)。如果PVE確認結(jié)果是拒絕，則TrE605執(zhí)行重啟并進行重新確認(690)。
[0142]可選地，在PVE609對所計算的驗證數(shù)據(jù)與所報告的驗證數(shù)據(jù)進行比較之后(668)，PVE609可向DMS611發(fā)送失敗組件列表(678)。由DMS611來判斷是否能夠進行更新(680)，如果是的話，則準備OTA更新(682)。還由DMS611來確保在V_DB613中存在用于更新的RM (684)。DMS611向SeGW607發(fā)送帶有重新確認指示的T_PVM (686)，并向TrE605發(fā)送重新確認觸發(fā)(688)。TrE605執(zhí)行重啟并進行重新確認(690)。
[0143]現(xiàn)在描述關于圖6A、6B和6C的過程的細節(jié)。為了執(zhí)行平臺確認，TrE要收集以下數(shù)據(jù)，將其包括在確認消息中，并將消息發(fā)送至SeGW:設備信息——例如Dev_ID、制造商、TrE能力和屬性(包括RoT) ；TrE信息一包括ID、證明信息、制造商、構(gòu)建版本和可選的模型、結(jié)構(gòu)、序列號；驗證數(shù)據(jù)一可包括平臺配置寄存器(PCR)值或簡單的包括在本地驗證中失敗的組件的列表或受本地驗證失敗的組件影響的功能列表；驗證綁定——例如通過PCR值的簽名或失敗組件或受影響功能的列表；組件指示符(CInd)-組件Clist有序列表，還可包括組件參數(shù)；以及時間戳(可信或不可信的)。
[0144]所述指示符-組件有序列表及其參數(shù)可以包含例如以下數(shù)據(jù)字段的項:索引、組件指不符(component_indicator) CIncU 組件參數(shù)(component_parameters)。CInd提供了對組件的參考，其可以是URN形式的(例如URN: //vendor, path, to/component/certificate)。組件列表可以通過例如指向RIM證書、RIMc來指示用于確認的RIM。
[0145]在設備中，確認消息可以額外包括設備信息一例如ID、證明信息、制造商、模型、版本、結(jié)構(gòu)、序列號、TrE性能和屬性(包括RoT)、在階段(1、2、3)進行了完整性檢查的設備的安全策略和模塊、硬件(HW)構(gòu)建版本號，并且可以包括軟件(SW)版本號和完整性測量數(shù)據(jù)。
[0146]如果需要TrE特定信息，則該TrE特定信息可描述是怎樣在設備中實現(xiàn)TrE的。同樣地，TrE信息可提供關于設備的信息和關于可信環(huán)境的分隔信息，例如，TrE是否是經(jīng)認證的IP組件。因此設備的證明機構(gòu)可以是有用信息。
[0147]盡管對SAV優(yōu)選地采用使用RM進行確認的方法，但其完全是可選的。其在此用作基本例子，其他方式可與此不同。例如，有的確認方式不從RM重新計算驗證數(shù)據(jù)，有的甚至執(zhí)行PVM時完全不需要RM。
[0148]如果確認信息與認證綁定(例如通過安全信道)，則驗證綁定也是可選的。
[0149]SeGW會對所接收的時間戳與本地時間進行檢查/比較，以檢測差異。如果所報告的時間戳與本地時間不符，則SeGW根據(jù)所報告的時間戳的屬性來進行操作。如果設備的時間戳是可信時間戳，并出現(xiàn)差異，則SeGW會觸發(fā)對TrE及其可信時間源的重新確認。在不可信時間戳的情況下，SeGW將其自身的可信時間戳施加在消息上。如果設備不能提供可信時間戳，則SeGW可添加可信時間戳，作為對重放攻擊的防護。
[0150]設備信息和TrE信息是可選的。Dev_ID提供對設備信息和TrE信息的參考。由于并不是所有MNO都知道會連接至網(wǎng)絡的設備以及所有的TrE，因此，可由數(shù)據(jù)庫來提供所有TrE信息數(shù)據(jù)，例如映射，該數(shù)據(jù)庫可由MNO查詢，以獲取任一特定Dev_ID的TrE信息。TrE信息可位于TrE_certificate中`。該TrE_certificate應由TrE或TTP的賣方簽名。
[0151]在第一種方式中，如果確認消息中沒有驗證數(shù)據(jù)/綁定，則可以簡單的方式來執(zhí)行PVM。只有驗證了 TrE的屬性時才能這樣操作。策略判斷必須只依賴于TrE信息和組件列表。
[0152]這種方式的前提是在SeGW和設備之間進行相互認證。否則，如果例如設備改變運營商，則會發(fā)生信任問題。例如，其可能之前在遠程管理過程中，從假冒SeGW/MNO處接收了假冒RIM0
[0153]將URN用作對組件的指示符是有好處的，這是因為其使用唯一標識同時表示了組件和可獲得R頂或RM證書的位置。
[0154]在設備確認期間，設備向SeGW發(fā)送確認消息。當接收到該消息，SeGff檢查是否存在驗證綁定。該步驟確保了驗證數(shù)據(jù)的真實性。之后，SeGW創(chuàng)建PVM令牌(T_PVM)。該令
可用作令牌環(huán)(rolling token),在通信中從一個實體發(fā)送至另一個實體。每個實體都在發(fā)送該令牌前向其添加時間戳，以確保其時新性，并防止異步消息流。令牌上的時間戳可提供用于跟蹤令牌狀態(tài)的方法。該令牌在CN中從一個實體傳遞至另一個實體，甚至好幾圈，因此可由實體追蹤。
[0155]可選地，可在加載了時間戳的數(shù)據(jù)的鏈中加入實體ID。
[0156]T_PVM可包括Dev_ID。如果原始時間戳不存在或不可信，則T_PVM還可包含由SeGW所發(fā)布的新的時間戳?；蛘撸琓_PVM可包含來自確認消息的原始時間戳。
[0157]可以使用時間戳來防護重放攻擊。該攻擊可與現(xiàn)時或單增計數(shù)器相結(jié)合，或甚至由其替代。還可使用時間戳來評價確認數(shù)據(jù)的時新性。最好將上述兩種目的相結(jié)合，并且這也是可由時間戳提供的。
[0158]假設SeGW、PVE和DMS之間的所有通信對于完整性、真實性和機密性來說都是安全的。因此，對于任何內(nèi)部消息，都不采取強制措施來建立這些安全屬性。但是，如果需要的話，也可以采用適當措施來保護整個或部分消息。這些措施可以包括加密通信信道、相互認證和消息上的簽名。SeGW維護令牌數(shù)據(jù)庫T_DB，該數(shù)據(jù)庫中包含所有處于活動狀態(tài)的T_PVM。
[0159]在第一種方式中，為了之后由DMS進行的設備管理，T_PVM可包含通信秘密，以用于在DSM和TrE之間構(gòu)建安全通道，例如TLS證書。
[0160]SeGW從確認消息中獲取下列數(shù)據(jù):確認數(shù)據(jù)、TrE信息和Clist。在將這些數(shù)據(jù)與令牌T_PVM —起發(fā)送之前，上添加時間戳，并將其轉(zhuǎn)發(fā)至PVE。SeGW可檢查確認消息的格式和其中的部分，以減輕不良形式數(shù)據(jù)攻擊的威脅。否則，攻擊者可能會試圖修改受攻擊的TrE的確認消息中的數(shù)據(jù)，從而在PVE處對該數(shù)據(jù)的完全檢查會使系統(tǒng)產(chǎn)生錯誤或失敗。
[0161]在Dev_ID與相應H(e)NB的標識(H(e)NB_ID)之間進行分隔是有用的。雖然兩者之間的關聯(lián)是一對一的，但是從任務分隔(SeGW 了解TrE，PVE 了解H(e) NB)，以及可能的尋址/管理角度來看，這種分隔是有意義的。在這種情況下，會存在中間步驟，其中PVE使用所接收的H(e)NB_ID從數(shù)據(jù)庫HNB_DB中查找Dev_ID。
[0162]PVE是決定設備有效性的實體。即，在策略系統(tǒng)的語言中，PVE是策略決定點(PDP)0在嚴格的任務分隔方法中，其是PVE系統(tǒng)中唯一的rop。其依賴SeGW和DMS來強制策略，例如用作策略強制點(PEP)。在通常描述中，PVM不了解策略是怎樣生成的，以及該策略在哪進行存儲/管理的問題，例如，PVE是從哪里獲得策略的。在下述一些更具體的方式和次要的方法中(特別是參量確認和最小確認)，給出了一些策略情況和操作的示例。通常，對確認策略的判斷不僅依賴于單個組件的有效性，還依賴于Clist中所包含的其他數(shù)據(jù)。特別是，需要評價允許的參數(shù)(范圍)和加載順序(Clist是有序的)。
[0163]由PVE所執(zhí)行的確認過程中所出現(xiàn)的失敗情況有一些基本類型。例如，失敗情況Fl表示“TrE失效”的情況。通過其認證的Dev_ID和所發(fā)送的TrE信息，PVE將該設備和/或TrE標記為不可信。
[0164]另一種例子失敗情況F2表示三種情況的“驗證數(shù)據(jù)失敗”。情況F2a表示完整性測量/驗證數(shù)據(jù)不匹配。這表示設備安全啟動進程失敗，和/或設備中存在錯誤和/或超期的RM和/或RM證書，之后該設備啟動無效組件。情況F2b表示RM丟失，即，用于組件的RIM丟失，需要從別處獲得。情況F2c表不RIM證書超期。
[0165]失敗情況F3表示兩種情況的“Clist策略失敗”。對于情況F3a，單個組件有效，但配置不符合策略，例如加載順序，或不期望的組件或參數(shù)。情況F3b表示配置未知，這樣就不存在可用的Clist的“已知良好值”。
[0166]失敗情況F4表示“確認前設備認證失敗”，當將認證與確認綁定，并且設備認證在確認之前時使用該情況。F4情況包括指示了設備證書超期的F4a情況。[0167]現(xiàn)在描述對所述失敗情況進行檢測和處理的方法。對于失敗情況Fl，PVE使用所接收的TrE信息來查詢本地確認數(shù)據(jù)庫(V_DB)。該TrE信息結(jié)構(gòu)包含關于TrE的證明、制造商、結(jié)構(gòu)、模型、序列號的詳細信息。該確認數(shù)據(jù)庫V_DB存儲關于哪個TrE可被認為可信的信息。例如，其可以執(zhí)行策略以信任特定賣方、模型或其他類似標識。如果根據(jù)TrE信息的評價結(jié)果，TrE不可信，則PVE可向SeGW發(fā)送包含該信息的消息。之后，SeGW可根據(jù)該消息進行適當?shù)牟僮鳌VE令牌添加聲明(例如附加數(shù)據(jù)字段)，該聲明包含拒絕接入的原因，例如錯誤/不可信的制造商。PVE在T_PVM上添加時間戳和簽名。將該T_PVM轉(zhuǎn)發(fā)至SeGW。之后，SeGW可驗證該時間戳(重放防護)和簽名(防止假冒發(fā)送者)。之后，SeGW拒絕網(wǎng)絡接入和設備認證，并阻止進一步認證嘗試。
[0168]在拒絕進行網(wǎng)絡接入和設備認證的情況中，如果確認和認證是綁定的，則需要停止認證過程。
[0169]在第一種方式中，可以使用根據(jù)特定屬性的設備黑名單，該屬性例如是制造商、設備版本和其他屬性。
[0170]PVE也可使用Dev_ID和TrE信息，對未知TrE首先觸發(fā)與RM更新過程類似的乂_DB更新過程。
[0171]對于失敗情況F2，PVE從V_DB為所接收的Clist中的所有組件獲取RM。確認數(shù)據(jù)庫V_DB中只存儲經(jīng)過證明的RM。必須將相應的RM證書安全地存儲在V_DB中。
[0172]在一個實施方式中，可在查詢V_DB前檢查RM證書，隨后可對其進行丟棄?？商鎿Q地，可為安全目的存儲R頂證書。例如，由于MNO持續(xù)地從可信第三方獲取RM及其證書，因此MNO可使用該證書來向檢查方證明其在設備管理中的服從性。
[0173]對于失敗情況F2a，PVE可從所查找的RM計算出正確的驗證數(shù)據(jù)，并將其與在確認消息中接收的驗證數(shù)據(jù)進行匹配。
[0174]如果所計算的正確的驗證數(shù)據(jù)與確認消息中的驗證數(shù)據(jù)不匹配，則設備的安全啟動進程可能已經(jīng)受到攻擊，或可能在設備中存儲了錯誤的RM，并可能已經(jīng)在安全啟動進程中加載了無效組件。PVE可將在確認消息中或?qū)VE單獨請求的應答中所發(fā)送的測量值與RIM進行比較，以檢測失敗組件。
[0175]根據(jù)F2a策略，可應用多種選擇。在拒絕的情況中，PVE可以將確認的結(jié)果發(fā)送給SeGW。SeGW可拒絕網(wǎng)絡連接或?qū)⒃撛O備至于隔離網(wǎng)絡中。在更新的情況中，在接收到指示驗證數(shù)據(jù)失敗的確認結(jié)果(T_PVM)之后，DMS可根據(jù)管理過程來啟動管理進程，以替換確認失敗的組件。DMS可將T_PVM和指示符一起發(fā)送至SeGW，該指示符表示確認失敗，設備將重新確認。DMS可向設備發(fā)送正確的RM，并觸發(fā)重啟。當重啟時，設備可使用新的RIM重新認證和重新確認。如果驗證數(shù)據(jù)再次錯誤，則該設備可能不能通過遠程管理過程恢復。為了防止無限的重啟循環(huán)，DMS可將Dev_ID與時間戳一起存儲，該時間戳表明發(fā)送遠程重啟觸發(fā)的時間。如果DMS接收到命令要再次執(zhí)行更新，則DMS可檢查是否已經(jīng)存儲了 Dev_ID。如果存在多個存儲項，則時間戳可指示短重啟周期，表明該設備不能被恢復。如果在確認中沒有使用RM，則此處所述的用于對失敗情況類型F2進行處理的方法是可選的。
[0176]在另一種方式中，根據(jù)驗證數(shù)據(jù)，例如PCR值，PVE可使用數(shù)據(jù)庫V_DB的特殊部分，該部分通過PCR值緩存了可信配置。PVE可為有效配置查找驗證數(shù)據(jù)表，例如在PCR值的情況中為哈什表。如果找到了匹配，則確認立即成功。在乂_08中為有效配置存儲預先計算的PCR值對以相同配置運行的設備類型非常有用，其中哈什值是相同的。不同于將所有組件與RIM進行比較，可比較單個合成哈什值，從而降低了計算開銷，加快了確認進程。
[0177]如果沒有發(fā)生策略失敗的情況，則該設備有效。PVE可將該消息發(fā)送至SeGW，SeGff可以允許對CN進行連接。
[0178]對于失敗情況F2b，可從可信第三方(TTP)處獲得RM。如果一個(或多個)組件的RM沒有存儲在V_DB中，則PVE將丟失RM的列表發(fā)送至RIMman。之后，RIMman嘗試從TTP獲得(經(jīng)證明的)RM。Clist包含組件指示符CInd (例如URN)，RIMman可通過該指示符標識出組件，并獲得關于查找相應R頂證書的位置的信息。RIMman為新RM執(zhí)行RM獲取，包括對存儲到V_DB中的RMc進行驗證。RIMman對存儲CIncU RIM和RMc的V_DB執(zhí)行更新。RIMman向PVE通知V_DB的更新，之后PVE可從V_DB獲取丟失的RM。
[0179]可替換地，可從設備處獲得RIM。如果在確認消息中，設備表明其能夠向網(wǎng)絡提供所存儲的RMc (包括RM)，則PVE可向該設備請求確認時丟失的RM和RMc。這可作為找回RM的備用辦法。由于設備在安全啟動中已經(jīng)使用過所有RM，因此，設備中存在全部RIM0如果PVE不能找到一些組件的RM，則PVE將丟失RM的列表與T_PVM —起，加上新的時間戳，發(fā)送至SeGW。SeGW執(zhí)行與設備的協(xié)議，以查找RMc。SeGW將所接收的RMc添加上時間戳，并加載T_PVM上，并將該T_PVM令牌轉(zhuǎn)發(fā)至PVE。PVE將所查找到的RMc轉(zhuǎn)發(fā)至RIMman。之后,RIMman驗證所接收的RIMc是由可信實體所發(fā)送的，并且有效。RIMman對該新RM進行RM獲取，包括將對存儲到V_DB中得RMc進行驗證。RIMman執(zhí)行V_DB更新，之后向PVE通知該V_DB更新。之后，PVE可從V_DB中獲得經(jīng)驗證的RM，并接著進行確認。如果在查找和獲取步驟后，該組件的RM依然丟失，則PVE不會再向設備請求RMc，而是從TTP請求獲取RM，正如上文所述。任何從設備或TTP獲得的RIM都一樣可按照數(shù)字證書的方式對可信度進行驗證。
[0180]PVM組件之間的信任模型決定了從設備獲取RM的操作順序。PVE不信任來自設備的RM/RMc，而要等待其進入V_DB，進入V_DB只能由RIMman在檢查了該數(shù)據(jù)的可信度后才執(zhí)行。PVE也可在與RIMman獲取RM同時，開始根據(jù)從設備所接收的RM重新計算驗證數(shù)據(jù)，但必須等待RIMman對其可信度的決定結(jié)果。
[0181]由于其僅在CN內(nèi)部發(fā)送，因此可在受到整體性保護的附加消息中發(fā)送該RMc。該包含RMc的消息必須可與T_PVM鏈接。
[0182]對于設備，可由外部實體來進行獲取RM的進程，且該進程可擴展為設備和PVM結(jié)構(gòu)完全獲取進程。這可在PVM結(jié)構(gòu)內(nèi)標記為分布式RM獲取。
[0183]所有從PVE發(fā)送至RIMman的消息都必須受到格式和內(nèi)容的限制，以確保消息的整體性并減輕例如錯誤消息的攻擊。消息必須包含用于組件的單獨URN，用于指示可取回參考測量的位置。
[0184]對于失敗情況F3，PVE從配置策略數(shù)據(jù)庫C_DB中獲取關于允許配置的策略。該配置策略數(shù)據(jù)庫C_DB包含了根據(jù)Dev_ID的所允許的配置。由CPman對該C_DB進行管理。該C_DB還可包含策略操作，例如對一段時間內(nèi)斷開連接且沒有進行確定的設備進行所期望的更新。PVE根據(jù)Clist中的信息對從CPman所接收的策略進行評價。如果評價結(jié)果產(chǎn)生F3a或F3b中任一種失敗情況，則可使用不同操作。
[0185]對于拒絕，PVE將關于失敗的配置策略的消息加載在T_PVM上，并在該T_PVM上添加時間戳和簽名，并將其發(fā)送至SeGW。之后，SeGW驗證時間戳(重放防護)和簽名(防止假冒發(fā)送者)。之后SeGW拒絕網(wǎng)絡接入和設備認證(并阻止進一步的認證嘗試)。如果確認和認證綁定，則停止認證過程。
[0186]如果Cl iSt未知，并從而在C_DB中找不到(失敗情況F3b )，或?qū)τ贑l ist中的組件不存在策略(F3a的特殊情況)，則PVE調(diào)用CPman從TTP中查找配置策略。如果CPman能夠獲得新的配置策略，則CPman更新C_DB，并向PVE發(fā)送帶有指示符的消息，該指示符指示所更新的配置策略。
[0187]如果該更新包含新組件(參考F3a)(通過從CPman向PVE發(fā)送包含該新組件標識符的消息)，能夠保持C_DB與V_DB的一致。之后，PVE將關于該新組件的必要信息轉(zhuǎn)發(fā)至RIMman,以獲得該組件的更新或新的RM。在此，我們希望能夠保持配置和RM管理的管理過程相互分離，從而可獨立地操作組件Cman和C_DB與RIMman和V_DB。如果策略需要對設備更新，則由PVE觸發(fā)該更新過程。
[0188]作為一個簡單策略的例子，C_DB可包含允許配置的列表。PVE將所接收的Clist轉(zhuǎn)發(fā)至CPman，該CPman反過來將該Clist與所存儲的允許配置進行匹配。如果沒有找到匹配，則檢測到失敗情況F3b。由于在設備管理過程中當前確認進程可能是設備更新之后的重新確認，因此可能需要檢查更新。在該管理過程期間，設備配置可能發(fā)生了變化，并可能需要與C_DB中新的配置進行驗證。
[0189]此處所述是重新確認過程的例子?？墒乖O備一旦經(jīng)網(wǎng)絡認證，就幾乎不再重啟，除非出現(xiàn)沒電這樣未安排的情況。對設備進行重新確認可以是執(zhí)行環(huán)境的常規(guī)部分。周期性的重新確認可使網(wǎng)絡確信設備正以預定狀態(tài)進行操作，從而減小了執(zhí)行惡意代碼的風險。重新確認還能使認證過程再次啟動，從而保持了密鑰交換的更新，并重新建立了安全通信通道。設備重新確認存在兩種觸發(fā)，一種是由網(wǎng)絡觸發(fā)，另一種是由設備觸發(fā)。此處所述的重新確認的方法可用于任何確認方法。
[0190]此處所述的是由設備啟動的重新確認的示例?？梢园粗芷谛缘臋C制來進行設備啟動的重新確認。根據(jù)設備的使用頻率，MNO可以在設備的設置過程中設定周期性重新確認安排。在所安排的時間，設備會啟動重啟順序，該重啟順序會觸發(fā)再次進行確認進程以及認證。同時，如果設備需要進行軟件更新，則還可啟動相應的OAM過程。如果設備在期望的時間范圍內(nèi)不進行重新認證/重新確認，則可由CN觸發(fā)重新確認。對于只能由設備啟動的重新確認，運營商對重新確認過程不具有控制力。如果大量設備按相同安排進行操作，例如每月第一天，則會增加CN結(jié)構(gòu)的載荷。
[0191]此處描述的是由網(wǎng)絡啟動的重新確認的示例。與由設備啟動的情況一樣，網(wǎng)絡啟動的重新確認可以按周期性的機制進行，但是也可在網(wǎng)絡由于安全原因而認為需要的任何時間進行。運營商還可將重新確認設置為策略的一部分，從而運營商將設備中的模塊編程為在所編程的時間間隔內(nèi)執(zhí)行重新確認。可通過向設備發(fā)送指示重新確認請求的IKEv2消息來觸發(fā)重新確認。可使用通知負載來承載為設備新定義的重新確認觸發(fā)代碼。
[0192]PVE可周期性地向SeGW發(fā)送重新確認指示符。為了對所發(fā)送的所有請求保持追蹤，PVE將其與DEV_ID和時間戳一起存儲。之后，PVE周期性地檢查是否有任何設備忽略了該重新確認請求。SeGW可通過IKEv2協(xié)議將該請求轉(zhuǎn)發(fā)至設備。可在安裝時，根據(jù)主機方的請求設置重新確認消息，從而降低設備中斷的風險。[0193]設備接收IKE消息，該消息的通知負載指示重新確認請求。之后，設備啟動重啟順序，其中重新建立對網(wǎng)絡的確認和認證。如果設備受到攻擊以至于忽略了該重新確認請求，則PVE可在監(jiān)視所有處于活動狀態(tài)的重新確認請求的過程中，檢測到該情況。PVE可將失敗的重新確認發(fā)送至SeGW，SeGW可采取適當?shù)牟僮?，例如將該設備置于隔離網(wǎng)絡中。
[0194]另一種由網(wǎng)絡啟動的重新確認的方法涉及向設備發(fā)送重啟信號，觸發(fā)重啟，從而在安全啟動進程中進行重新確認。
[0195]在另一種方法中，還可通過來自其他網(wǎng)絡實體的請求來進行設備的重新確認。如果設備制造商懷疑其設備已經(jīng)受到大范圍的攻擊，則制造商可聯(lián)系ΜΝ0，并請求重新確認。這可通過由MNO戰(zhàn)略部門的處理來判斷是否進行重新確認而完成。PVE或HMS可以啟動重新確認和重新認證。
[0196]此處所述是平臺管理的示例。DMS是負責設備管理的主要實體。根據(jù)所接收和所存儲的設備信息，例如賣方、硬件/軟件配置/TrE能力等，DMS能夠啟動軟件更新、配置改變和OTA設備管理過程。管理操作通常是由所發(fā)送的確認數(shù)據(jù)、來自PVE的確認結(jié)果和C_DB中的策略(例如所需目標配置)來決定的。
[0197]DMS可以與設備的TrE建立安全通道。DMS可使用T_PVM令牌來獲取設備的Dev_ID、最近報告的確認數(shù)據(jù)和Clist。通過發(fā)送帶有指示符的T_PVM，DMS使用Dev_ID來詢問SeGff,以與設備TrE建立安全通道，其中該指示符指示將設備的狀態(tài)從“工作”設置為“管理”。從而，SeGff保存該令牌，可不提供回程鏈接(例如通過隔離)，并等待DMS確認管理操作結(jié)束。
[0198]根據(jù)DMS的管理操作，設備可在軟件更新之后，例如通過重啟來進行重新確認。之后可進行重新確認，其中，通過使用來自之前確認的T_PVM來維持PVM系統(tǒng)的狀態(tài),并可以不再生成新T_PVM。在這種情況下，DMS向SeGW發(fā)送經(jīng)過更新的T_PVM令牌，其中的設備狀態(tài)指示符從“管理”變?yōu)椤爸匦麓_認”。SeGW保有等待進行重新確認的設備的列表，當設備請求網(wǎng)絡接入時，其從該列表中查找設備。之后SeGW可等待設備一段特定時間進行重新確認。之后，將重新確認的結(jié)果發(fā)送回DMS，以確認管理過程成功結(jié)束。
[0199]在設備的系統(tǒng)模型中會產(chǎn)生進行重新確認的需求。從DMS下載的新組件恰好在下一安全啟動進程之前插入設備配置。因此，需要觸發(fā)重新確認，以作為平臺管理的結(jié)束步驟。由于設備必須重啟，且若平臺確認進一步與平臺認證綁定，則重新確認可以包括切斷現(xiàn)有用于平臺確認和管理的連接。在這種情況下，像上一段描述的那樣，SeGW可以為重新確認維持狀態(tài)。
[0200]隨著與設備的TrE的安全通道的建立，DMS可以安裝/卸載軟件(SW)組件(例如新Sff組件)、改變配置和觸發(fā)重新確認。
[0201]在另一種方式中，設備可以通過確認消息中的標記(flag)來指示重新確認。這避免了對接近SeGW的每個設備查找重新確認列表?？稍诎踩M程，(例如由TrE組件所執(zhí)行的進程)中設置該標記，這樣任何設備都不能通過不設置該標記而進行重新確認。
[0202]該步驟和以上步驟可在SeGW端而不是PVE端進行，否則SeGW會自動生成新的令牌。特別是，這些步驟包括進行設備管理的協(xié)議步驟，在該步驟中，SeGff必須對要求進行設備重啟的重新確認進行追蹤。由于設備在重啟后，會再次連接從而再次認證，因此，SeGW必須對將要重啟進行重新確認的設備進行追蹤，否則，SeGW會將其連接和認證嘗試認為是首次連接，從而發(fā)布新的令牌。因此，在SeGW中包括維護重新確認列表。
[0203]連續(xù)在多輪重新確認中使用T_PVM有助于檢測重復出現(xiàn)的更新失敗和其他類型的操作異常。
[0204]如果DMS向設備安裝新組件，則需要確保在從DMS發(fā)送至TrE的相同管理消息中，包含用于軟件的RM。可由TrE負責RM的安全存儲和其本地管理。如果需要的話，在安裝組件后，由DMS觸發(fā)重新確認。可向PVE發(fā)送用于該新軟件的RM，PVE通過RIMman將該RIM存儲至V_DB中。DMS相應地使用CPman更新配置策略數(shù)據(jù)庫C_DB?？稍谠O備進行重新確認前，能夠在V_DB中使用用于新組件的RM，以使PVE對新配置進行確認。在配置變化的情況下，例如，如果DMS改變了用于給定組件的參數(shù)，則DMS可通過CPman對C_DB進行更新。
[0205]TrE可為安全更新和管理功能提供安全運行環(huán)境。該功能確保了受攻擊的設備在軟件或組件更新失敗的情況下，至少能進入救援模式。在失敗情況下，DMS可使用回退代碼機制(FBC)用于設備恢復。這使設備能夠變?yōu)樵紶顟B(tài)，在該狀態(tài)中，可通過DMS管理方法對主要代碼進行更新。
[0206]為了避免出現(xiàn)競爭情況，可在令牌傳遞后，由DMS發(fā)送至TrE的消息來觸發(fā)重新確認。否則，設備可能會在SeGW接收到令牌并準備進行重新確認之前，嘗試進行重新確認。
[0207]在另一種方式中，SeGW可為重新確認列表中每個設備的重新恢復嘗試或失敗嘗試次數(shù)計數(shù)“n”，在達到計數(shù)后可將設備列入黑名單、隔離或觸發(fā)字段內(nèi)維護，或其結(jié)合。
[0208]在另一種方式中，可在T_PVM中包含，或可從T_PVM中獲取用于建立安全通道的通信秘密，而不涉及SeGW。
[0209]另一種方法可以不拒絕連接到設備，而是禁止PVM中不能通過確認或不能替換或更新的組件。通常，DMS可發(fā)送禁止CInd和重新確認消息，其有助于減輕經(jīng)歷如下所述的運營商鎖定的風險。PVE可用于防止在設備和運營商之間出現(xiàn)“信任之爭”。各種用于防止出現(xiàn)“信任之爭”的方法都可用。在一個示例方法中，可通過強制進行重新確認時不包括Clist中的該組件來禁止設備組件。這可當組建的有效性更新不可用時使用。在另一方法中，可強制改變加載順序。在另一方法中，強制改變參數(shù)，其可影響或不影響RIM。強制改變參數(shù)需要DMS從PVE獲得有關所有設備組件的所需信息，而并不僅是那些確認失敗的設備組件。
[0210]在PVE中，通常不需要向設備發(fā)送Rna正書。在現(xiàn)有PVM結(jié)構(gòu)中，驗證和管理是運營商網(wǎng)絡的任務，其位于RIMman中。因為設備信任網(wǎng)絡，所以設備可信任在管理過程中所接收的RM和CInd。而另一方面，可信計算群組(TCG)移動電話工作組(MPWG)將由可信設備所執(zhí)行的R頂獲取定義為分散(de-centralize)過程，其中設備還要對所獲得的由MTM保護的RM證書進行驗證(在對其安裝之前)。這兩種形式不是相互排除的。DMS可將RM與其他數(shù)據(jù)一起發(fā)送，而TCG MPWG兼容設備可根據(jù)TCG規(guī)定來安裝。這是PVM與TCG MPffG為安全啟動所定義的設備管理之間的不同點。
[0211]現(xiàn)在描述驗證數(shù)據(jù)的示例。發(fā)送驗證數(shù)據(jù)(例如以PCR值(其為單個測量的聚合哈什值)的形式)以及為認證綁定驗證數(shù)據(jù)是TCGTCG規(guī)范所提供的技術標準。但是，根據(jù)TCG規(guī)范建立驗證數(shù)據(jù)和進行綁定計算的耗費很大，特別是對有很多待測量組件的設備。這通常通過此處所述的加密擴展操作來解決——基本上為從兩個舊哈什值創(chuàng)建新哈什值。這會顯著減慢設備的啟動進程，這在例如家庭環(huán)境中是不希望的。[0212]同時，由于其發(fā)送與關于測量結(jié)果的信息相類似的信息，因此在RIM和驗證數(shù)據(jù)之間存在冗余。如果正確執(zhí)行了安全啟動，則TrE將測量值與RM進行比較，并且只加載兩者都匹配的組件。因此，Clist中所分配的RM承載了所有有關驗證數(shù)據(jù)的信息。事實上，由于驗證數(shù)據(jù)被認為是所述測量值的集合，因此，RM可承載比驗證數(shù)據(jù)更多的信息。驗證數(shù)據(jù)是實際測量值的唯一加密簡略形式。在一個實施方式中，可將PCR值用作驗證數(shù)據(jù)。
[0213]針對驗證數(shù)據(jù)的爭論的基本假設是安全啟動進程正確地將實際測量與Clist中所示的RM進行比較。因此，從安全的角度來說，存在一個重要的原因，即為什么驗證數(shù)據(jù)能增加被確認的設備的信任度。當設備具有錯誤的RM，或?qū)y量值與假冒RIM進行比較時，會出現(xiàn)這種情況。
[0214]還有進一步的觀點支持保留驗證數(shù)據(jù)一由于在安全啟動進程中所產(chǎn)生的，具有高保護性的數(shù)據(jù)，唯一地標識了所達到的系統(tǒng)狀態(tài)——即使是在安全啟動或一元(monadic)方法(例如AuV)的情況中。事實上，安全啟動本身并不能對其他確認數(shù)據(jù)進行完整性保護，在本情況中，確認數(shù)據(jù)可以僅是沒有測量值的組件列表。該CId列表還告訴確認器在哪里和怎樣獲得有關組件的信任信息(例如從TTP處)。
[0215]攻擊者會試圖操縱確認數(shù)據(jù)(Clist)，將較低信任度的組件標識替換為(所獲得的)具有較高信任度的組件的CId (“組件信任評價”)。確認設備(TrE)對該偽造數(shù)據(jù)簽名，并進行正確的確認——如果沒有驗證數(shù)據(jù)，則沒辦法在內(nèi)部檢測到該操縱。
[0216]在一定程度內(nèi)減輕該攻擊的方法是安全啟動引擎通過將數(shù)據(jù)封閉(seal)至所述狀態(tài)而使該數(shù)據(jù)為靜態(tài)(最新的PCR數(shù)據(jù))。確認時，需要解除對該數(shù)據(jù)的封閉，因此再次出現(xiàn)相同的安全缺口。并且，由于需要系統(tǒng)在SML封閉后保持靜態(tài)，因此限制了這種方法的靈活性。
[0217]因此，設備和確認器都非常需要具有驗證數(shù)據(jù)的確認數(shù)據(jù)，即使是在安全啟動的情況下。
[0218]此處所用的“驗證數(shù)據(jù)”與“對原始測量數(shù)據(jù)進一步處理所產(chǎn)生的數(shù)據(jù)(例如哈什)(之后對其進行驗證以找到匹配的RIM)”同義。在完成安全啟動后，該驗證數(shù)據(jù)唯一標識了平臺狀態(tài)。錯誤RM的出現(xiàn)可能是例如來自受攻擊的源，其可能對PVM系統(tǒng)整體產(chǎn)生更大影響，因此造成了極大風險。
[0219]一個具體的場景是其中位于運營商CN以外的可信RM源受到攻擊，例如被另一方攔截或欺騙。在檢測和糾正該攻擊之前，RM源會在正常的PVM平臺管理中向大量設備以及受攻擊的組件發(fā)送假冒RM。
[0220]在這種情況下，通常的修正辦法是(S卩，在公共密鑰基礎結(jié)構(gòu)(PKI)中的共同做法)廢止相應的RM證書。由于可信參考數(shù)據(jù)會位于設備中，因此這種做法會對設備增加負載。TRV修正會對整個設備范圍內(nèi)的RM、RMc和組件進行強制更新，但是實際上只有一小部分會受到攻擊的影響。這會引起巨大的網(wǎng)絡流量，對用戶造成不便。該設備支持能夠執(zhí)行授權TRV修正的機制和協(xié)議。
[0221]在這種情況下，在確認中可以生成和使用驗證數(shù)據(jù)。PVM系統(tǒng)可根據(jù)策略，為每個單獨的確認設備調(diào)用驗證數(shù)據(jù)使用。之后，PVE可以檢測受攻擊的設備，并僅管理該設備。在此稱之為“最小確認策略”。
[0222]現(xiàn)在描述基于令牌傳遞的PVM操作的示例。此處所述的PVM是異步進程。因此，受各種實體攻擊的PVM系統(tǒng)應有多種狀態(tài)，且其應能從進程的當前狀態(tài)中進行恢復，以減輕對分布式系統(tǒng)及其失敗狀態(tài)進行的各種已知的攻擊。
[0223]在一個例子中，可使用令牌傳遞來進行以下操作?？蓪eGW配置為是負責生成和管理令牌的實體，該令牌唯一地與確認進程相關。該PVM令牌不僅可以與確認TrE的標識綁定，還可以與有問題的單一確認進程綁定。該令牌傳遞方法包括重放/重新確認防護。確認嘗試能夠唯一地防止對舊認證進行重放，并通過頻繁的重復確認來提供一種檢測DoS攻擊的方法。通過令牌可以建立確認會話，從而允許PVM相關數(shù)據(jù)和消息與唯一確認之間建立唯一關聯(lián)。這也是評價時新性的前提。
[0224]由于可根據(jù)時間戳(不必被簽名)來生成確認令牌，因此可以控制確認數(shù)據(jù)的時新性，該時間戳最初是由SeGW生成的，之后在每個實體傳遞該令牌時，會被附加到時序列表。
[0225]另一種加入時新性的方法可以是在加載RoT后，立即從安全實時通信(RTC)中讀取時間，并使用該時間戳來建立聚合哈什鏈。另一種替換方法可以是使用順序計數(shù)器，該計數(shù)器在每個重啟周期增加，RoT可使用該計數(shù)器建立哈什鏈。
[0226]而另一種加入時新性的方法是完成階段I和階段2的檢查，開始與SeGW和PVE進行通信，之后使用SeGW/PVE所提供的現(xiàn)時，在將階段3的確認結(jié)果數(shù)據(jù)發(fā)送給SeGW之前，與階段3的檢查的進一步驗證綁定。這就確保了確認數(shù)據(jù)的時新性。
[0227]與在標準PVM中一樣，在多輪重復確認中連續(xù)使用T_PVM有助于檢測重復出現(xiàn)的更新失敗和其他類型的性能異常。SeGW可根據(jù)確認令牌的各種情況進行檢測和操作。例如，保持活動時間過長的令牌可以表明PVM普通失敗。SeGW可以在PVE和DMS中查詢該令牌的狀態(tài)，并根據(jù)該狀態(tài)進行操作。可將這種情況標記為確認超時。在另一例子中，在令牌處于活動狀態(tài)時可能會出現(xiàn)重新確認。這可以表示各種情況，例如意外重啟、電源用盡或DoS攻擊。在另一例子中，可能會在入侵檢測系統(tǒng)(IDS)中檢測到基于時間的形式，例如隨機的或周期性行為?？蓪⒃撛O備隔離或列入黑名單，還可觸發(fā)字段內(nèi)維護。
[0228]還可使用令牌來保護在PVM系統(tǒng)實體之間和PVM系統(tǒng)與設備之間所傳遞的數(shù)據(jù)的完整性。為此，其可以包含所要保護的數(shù)據(jù)的哈什值，例如Clist，或在處理失敗情況F2a時，丟失的RM的列表，以及指向該數(shù)據(jù)的指針。T_PVM中數(shù)據(jù)對象并不是作為整體存在的，因為這會對其造成過載，產(chǎn)生大量開銷，實際上，該開銷可能會產(chǎn)生特定DoS攻擊。
[0229]現(xiàn)在描述運營商RM屏蔽方法的示例。運營商RM屏蔽將大量來自各種外部源的用于設備組件的Rna正書替換為由運營商(或等同的“選擇歸屬運營商”(SHO))所生成的RIM證書，該運營商是設備希望與之建立回程鏈接的運營商。對于V_DB中的相同組件，只要這些SHo Rna正書(SHORMc)可用，在確認中該證書就優(yōu)于外部Rna正書。在設備管理中，由DMS向設備安裝SH0RM，在由TrE執(zhí)行的設備安全啟動中，其在設備本地依然優(yōu)于外部證書。
[0230]該SHORM可用作“第一級緩存”，以用于在確認中獲取RM證書?？蓪⑵渑c在本質(zhì)上指向技術上分隔的、高性能的V_DB子數(shù)據(jù)庫的特殊CInd相關聯(lián)。
[0231]運營商RM屏蔽適用于任何類型的高度移動設備，例如M2M設備(M2ME)。當移動設備進入新運營商的領域并進行確認時，可向該運營商提供指向另一運營商的CInd。該運營商可以以與移動設備漫游類似的方式接受該CInd，或按此處所述方法進行替換。
[0232]在運營商屏蔽的另一種方式中，當SHO決定不釋放由該SHO所生成的SHORMc的簽名密鑰的公共部分時，另一運營商很難，或甚至不能對來自該SHO的設備組件進行確認?？蓪⑦@種機制擴展為與傳統(tǒng)SIM鎖定過程所提供的鎖定具有相同級別的鎖定?？稍趨^(qū)域中首次部署設備時將運營商RM屏蔽用作存在周期的管理工具，以在設備首次與SHO進行聯(lián)系時，遠程“標記”該設備。
[0233]為了根據(jù)PVM建立運營商RM屏蔽，描述以下附加步驟，并參考上述原始PVM過程。在用于RM屏蔽的PVM設置中，RIMman將PVE和DMS配置為各自執(zhí)行在運營商RM屏蔽中的功能。在平臺確認中，PVE發(fā)送(單獨或與關于組件有效性的消息一起)消息，該消息包含目前V_DB中的SHORM所涉及的組件列表。將DMS配置為，對設備中將安裝該新SHORMc的組件執(zhí)行證書更新操作(不需要更新組件自身)。
[0234]在確認期間，PVE對SHORM不在V_DB中的組件進行標記(這與組件的任何RM和RIMc的可用性(例如正常PVM進程)不相關)。PVE向RIMman發(fā)送所標記的候選組件列表，該列表包含CInd和實際RM (RM需要該數(shù)據(jù)來生成相應的SHORMc (通常通過對其簽名而實現(xiàn)))，以進行運營商RM屏蔽。RIMman根據(jù)本地可用策略來判斷對所接收的列表中的哪些組件應用運營商RM屏蔽。
[0235]RIMman通過對各個RM簽名來生成用于這些組件的SH0RM。根據(jù)本地運營商策略來確定證書參數(shù)，例如有效性周期。RIMman生成指向V_DB中SHORMc的SHOCInd。RIMman向V_DB中附加新的SHORMc和SHOInd。在一種實施方式中，存儲所有的“舊”數(shù)據(jù)，例如V_DB中原始的CInd和RMc，以為之后的可追溯性和回退所使用。RIMman向DMS發(fā)送(CInd、SHOCInd)對的列表，指示DMS強制對有問題的設備進行RM指示符更新。DMS在正常的設備管理中，向設備TrE發(fā)送RIM指示符更新消息以及SHO數(shù)據(jù)，但是不進行組件更新。通過該消息，DMS可要求設備在之后的確認中僅使用SHOCInd。
[0236]除了安裝SHOCInd (也可能是SHORMc)以外，在設備上所進行的操作都取決于本地策略。精巧的設備會保存其原始制造商CInd，還可能保存相應的RMc。為了實現(xiàn)靈活性，設備會嘗試至少為每個組件保存用于各個運營商以及原始組件制造商/證明方的多個不同CInd。
[0237]DMS可強制設備進行狀態(tài)重新確認。當設備的RMc更新失敗時，需要進行狀態(tài)重新確認來避免循環(huán)操作。
[0238]現(xiàn)在描述運營商組件鎖定的示例。作為運營商RM屏蔽的擴展，運營商可能夠?qū)υO備或其組件在外部網(wǎng)絡中的操作進行控制和限制。這可按以下方法擴展為運營商組件鎖定。應被鎖定的組件部分被SHO使用例如對稱密鑰進行加密。對該修正過的組件執(zhí)行運營商RM屏蔽。在受保護和受控的空間內(nèi)，將解密密鑰發(fā)送給TrE (或nCC)，該空間只能由SHO授權接入。在確認時，當PVE接收到用于該組件的SHOInd時，SHO向TrE發(fā)送授權數(shù)據(jù)。之后，將組件的加密部分發(fā)送至TrE的安全操作空間，在此進行解密和操作。
[0239]因此，SHO鎖定的組件只能在設備對特定SHO確認時才能工作，該相同設備不能對另一運營商進行確認。
[0240]在另一種形式中，釋放解密部分，以在TrE外部進行操作。這樣做在安全性方面要弱于之前的方式，因為可通過轉(zhuǎn)儲(dump)設備存儲器而恢復全部組件。通過所獲得的完整組件，可重新生成RM，并可成功進行對另一運營商的確認，從而解除鎖定。
[0241]另一種實現(xiàn)組件鎖定的方式不需要在TrE中管理加密秘密，或由其他安全組件(例如通用集成電路卡(UICC))保護加密秘密?？赏ㄟ^使用組件修改來生成運營商唯一的SHORIM, SHORIMc和CInd。之后可將該數(shù)據(jù)用于代碼混淆和水印領域。
[0242]—種運營商組件鎖定的示例可涉及漫游運營商攔截另一運營商的設備組件或整個設備。期望上述基于TrE的方法來保護其余自由用戶設備免受此攔截。本質(zhì)上，設備應當針對該過程向用戶/主機方/原始SHO發(fā)出警告，并維護關于何時允許對組件進行鎖定和何時不進行鎖定的策略。
[0243]現(xiàn)在描述的示例方法用于在設備管理中，通過使用涉及特定PVM系統(tǒng)和運營商的特征的PVM，來對設備進行個別化。由PVM所管理的設備可處于與特定PVM系統(tǒng)和管理運營商相關聯(lián)的可信狀態(tài)。當漫游設備進入另一 PVM系統(tǒng)和運營商的領域時，該漫游設備會出現(xiàn)問題，即，需要該設備證明之前由誰管理其配置和可信度。一種為該設備實現(xiàn)獨立措施，以向另一端提供證據(jù)的方法是向該數(shù)據(jù)提供已經(jīng)簽發(fā)了該設備的尋址的數(shù)據(jù)。該消息的個別化證明了發(fā)送方的有意簽名。一種方法可以是在數(shù)據(jù)中包含由運營商簽發(fā)的Dev_ID。任何接收到該簽名數(shù)據(jù)的一方都可認為其相應消息及其內(nèi)容都是由進行簽名的運營商專用于該特定設備的。在對方相信該進行簽名的運營商正確實施了對設備認證的驗證(例如，通過Dev_ID)時,這樣做有效。如果這樣做不合理，則可由簽名運營商對Dev_ID的整個認證證書簽名來代替。所簽名的數(shù)據(jù)還可包括實際的RM，由于這將建立另一個RMc而導致添加特定的冗余，其使用Dev_ID進行擴展。
[0244]現(xiàn)在描述兩種根據(jù)PVM建立個別化的有效方法。在一種方法中，RIMman在SHORMc中包含Dev_ID，只有在由設備維護RMc時，SHORIMc才可用，因此，在設備內(nèi)部存儲SHORMc(其中包括Dev_ID)。在另一種方法中，RIMman或DMS向(Dev_ID、CInd)對使用運營商簽名，且如果使用了 SHOInd，則向該SHOInd使用相同的運營商簽名。
[0245]現(xiàn)在描述將設備列入黑名單的示例?？梢詾樵O備建立黑名單，并根據(jù)該黑名單禁止網(wǎng)絡接入。該黑名單可至少包括Dev_ID，可選地包括TrE信息(證明、結(jié)構(gòu)、制造商、模型、序列號)。這種名單通常可由DMS訪問。在一個實施方式中，每個MNO管理其自身的黑名單，而DMS可訪問該名單或數(shù)據(jù)庫。使用Dev_ID來查詢特定設備是否被列入黑名單。之后，拒絕對該設備進行網(wǎng)絡接入。在另一實施方式中，可維護一個通用黑名單，其中每個MNO都列出惡意設備，該數(shù)據(jù)庫可由所有MNO讀取。必須保證每個MNO都只能將其自身的設備列入黑名單，但所有MNO都可讀取所有條目。這種通用數(shù)據(jù)庫需要更多的管理和維護工作?？蓪⑸鲜鰧嵤┓绞脚c替換實施方式相結(jié)合。
[0246]當PVE接收到令牌T_PVM時，PVE在該T_PVM上加上時間戳，并將其轉(zhuǎn)發(fā)至DMS，DMS從該令牌中獲取Dev_ID，和可選地獲取TrE信息。DMS通過使用Dev_ID (且如果需要或存在的話還包括TrE信息)來查詢黑名單。如果設備在黑名單中，則DMS將包含T_PVM的消息作為黑名單項發(fā)送至SeGW。該消息可包含DMS的時間戳。之后SeGW可拒絕對CN的連接。
[0247]可通過使用TrE信息字段的擴展信息來實現(xiàn)另一種方式。其可將特定賣方、模型、序列號范圍等列入黑名單。根據(jù)黑名單行為的復雜度，本地以MNO為中心的方案會比中央式黑名單更容易實施。
[0248]現(xiàn)在描述將設備列入白名單的示例。可為設備建立白名單，根據(jù)該白名單允許網(wǎng)絡接入。白名單通常至少包括Dev_ID，可選地包括TrE信息，例如結(jié)構(gòu)、制造商、模型、序列號。這種名單通?？捎蒁MS訪問。[0249]當PVE接收到令牌T_PVM時，PVE在該T_PVM上加上時間戳，并將其轉(zhuǎn)發(fā)至DMS。DMS可從該令牌中獲取Dev_ID，并可選地獲取TrE信息。DMS通過使用Dev_ID (如果需要或存在的話，可選地使用TrE信息)來查詢白名單。如果設備在白名單中，則DMS將包含T_PVM的消息作為白名單項發(fā)送至SeGW。該消息可包含DMS的時間戳。之后SeGW可允許對CN的連接。
[0250]可通過使用TrE信息字段的擴展信息來實現(xiàn)另一種方式。其可將特定賣方、模型、序列號范圍等列入白名單。根據(jù)白名單的行為的復雜度，本地以MNO為中心的方案會比中央式白名單更容易實施。另外，調(diào)節(jié)器可能會要求MNO維護黑名單，而不是白名單。
[0251]在另一實施方式中，每個MNO都維護白名單或數(shù)據(jù)庫，而DMS可訪問該名單。使用Dev_ID來查詢特定設備是否被列入白名單。之后，授權該設備進行網(wǎng)絡接入。
[0252]在另一實施方式中，可維護一個通用白名單，其中每個MNO都列出其自身的可信設備，該數(shù)據(jù)庫可由所有MNO讀取。必須保證每個MNO都只能將其自身的設備列入白名單，但所有MNO都可讀取所有項。這種通用數(shù)據(jù)庫需要更多的管理和維護工作。通用白名單設備的數(shù)據(jù)庫會需要MNO之間建立額外的可信關系。MNO A認為可信的設備能列入白名單，并能進入MNO B。這需要標準的和/或經(jīng)證明的設備確認過程來比較設備的可信級別?？蛇x地，可以將上述方式結(jié)合實施。
[0253]現(xiàn)在描述用于設備的隔離網(wǎng)絡的示例。建立用于設備的隔離網(wǎng)絡可能需要對運營商網(wǎng)絡進行額外改變。在該新網(wǎng)絡中，SeGW仍可用作CN的執(zhí)行屏障。由SeGW決定將哪些設備進行隔尚。
[0254]隔離中的設備對CN沒有直接接入，且向用戶不提供或提供受限的服務。在PVE評價驗證數(shù)據(jù)時，會發(fā)生確認?？筛鶕?jù)評價結(jié)果觸發(fā)新的操作。例如，可認為設備可信，并可連接至CN。在另一示例中，可檢測認為設備受攻擊或不可恢復。將該設備列入黑名單，并阻止其進行進一步的連接嘗試。在另一示例中，SeGW將確認結(jié)果與Dev_ID和TrE信息一起轉(zhuǎn)發(fā)至DMS。DMS可提供適當?shù)母?軟件變化，來對設備進行恢復?？上騍eGW通知更新，并由SeGW觸發(fā)對設備重新確認。如果應用更新成功，則確認成功，可授權進行網(wǎng)絡接入。
[0255]可將上述黑名單方法與隔離網(wǎng)絡結(jié)合使用。這能使運營商在可能的情況下，例如通過經(jīng)由OTA提供更新，來利用對設備的連接?？商鎿Q地，可使用黑名單來完全阻止設備。例如，如果設備不能被OTA措施恢復。字段內(nèi)替換/服務必須重視這種設備。
[0256]如果其他設備被列入灰名單中，則將其隔離。該灰名單中所包含的設備例如是新加入網(wǎng)絡的(來自另一 MNO的)；其連接時間還未達到足夠長的設備；具有可疑性能的設備；和存在安全警告(由賣方或獨立制造商發(fā)出)的設備。
[0257]現(xiàn)在描述參量確認的示例。在PVM期間，對于所加載的組件，驗證數(shù)據(jù)可能會依賴于配置參數(shù)。由于這些參數(shù)可能會頻繁變化，并在同樣兩個設備之中不同，因此，PVM的基本實施方式允許在確認期間明文發(fā)送參數(shù)。但是，這需要保存完整的參數(shù)數(shù)據(jù)庫，并要求同時在設備端和確認器端進行記錄。這會產(chǎn)生如下影響:1)參數(shù)設置會占據(jù)大量存儲器空間，并且當對其進行評價時，會減慢確認過程；和2)對每個設備大量存儲和評價參數(shù)會向第三方過多暴露設備配置，造成外泄。
[0258]一種在PVM進程中包含參數(shù)的方法是基于擴展哈什值的方法，即，將參數(shù)的哈什功能結(jié)果與組件的測量相連接。參數(shù)摘要值是對組件參數(shù)值進行順序化和二進制再現(xiàn)而生成的，之后使用該參數(shù)摘要對該組件現(xiàn)有的測量值進行擴展。因此，為了進行確認，可以以相似的方法來處理所有測量和參考值、RIM和RIMc，從而實現(xiàn)多種方式的參量確認。
[0259]在證書(例如X.509)與屬性證書(例如，參照參數(shù)來看待的屬性)的關系之間存在的類似問題，在此被表示為“屬性證書的非法(rigged)哈什值”，該問題可通過在參考測量和RMc中包含參數(shù)來解決。
[0260]現(xiàn)在描述診斷確認的示例。一種基于PVM概念的驗證的實施方式包括在設備中不具有RM的情況下允許加載組件的選擇。可以在設備上沒有運行重大安全軟件和足夠安全時，下載特定組件，但網(wǎng)絡需要知道該變化。在另一實施方式中，MNO建立了策略，即通常由設備對特定組件(例如由于頻繁變化)進行測量，但由網(wǎng)絡進行確認。并且，加載和測量未知組件可以是設備的默認操作，并將確認的任務交給網(wǎng)絡。網(wǎng)絡可將設備隔離，該設備反過來啟動設備的遠程OAM修正。例如，其可返回原始狀態(tài)，移除組件或采取其他措施。
[0261 ] 現(xiàn)在描述對失敗情況F2a的PVM診斷的示例。當PVE沒有向DMS發(fā)送產(chǎn)生了 F2a失敗的組件的列表時，可按如下來查找失敗組件。例如，設備可能沒有保存可用于向PVE示出以便與R頂進行比較的SML。在這種情況下，DMS可以不替換設備中的失敗組件一因為其不知道該失敗組件一而是在正常管理過程中，將Clist中的所有組件都替換為正確組件。一旦重啟和重新確認，由于未加載的組件在內(nèi)部驗證中失敗，因此設備還可將該未加載的組件列表包含在確認消息中。PVE甚至可以通過將之前確認的Clist與RM更新后的Clist進行比較來進行診斷。當在本地與正確的RM進行驗證時，現(xiàn)在丟失的組件在安全啟動中是沒有被加載的。這樣，丟失的組件就是需要替換的組件。之后，可在第二管理周期中對這些實際需要替換的組件進行替換。
[0262]如果設備報告無法加載組件(例如RM丟失或錯誤)，并將該組件的測量值發(fā)送給CN,則可以使用另一種方法來進行診斷確認。根據(jù)MNO策略，可觸發(fā)OAM修復進程來移除或修復組件。在另一種方式中，如果TrE檢測到組件的RIM丟失或錯誤，則允許設備直接請求進行OAM修復。
[0263]另一種方法可禁止組件而不是對設備拒絕連接，該組件在PVM中不能確認，且不能替換/更新。在這種情況下，DMS可發(fā)送用于組件的“禁止CInd”消息，并觸發(fā)該設備的重新確認。這可適用于加載了未知組件的情況。
[0264]另一種方法可由DMS指明在特定設備中允許哪些組件。如果設備在安全啟動期間加載和確認了所有組件，包括不允許的組件(例如，由于最近發(fā)現(xiàn)了安全漏洞，但還沒有可用的更新)，則DMS可通過SeGW向設備發(fā)送消息，該消息使設備禁止該組件。要求該設備進行重新確認。如果在重新確認期間沒有加載該組件，則DMS將該情況通知SeGW，SeGW隨即允許完成認證/確認。
[0265]現(xiàn)在描述最小確認策略的示例。由于啟動時的組件測量(例如,擴展PCR值,和將測量寫入生成Clist的SML中)會在啟動進程中產(chǎn)生一些延遲，因此，最小確認機制僅在特定情況下才要求設備進行確認。由于RIM和所存儲的測量值(例如PCR值)發(fā)送部分相同的或冗余的信息，因此，消除該冗余能夠節(jié)省消息和存儲容量。
[0266]如果可在設備上建立本地完整性測量、驗證和強制進程(例如，安全啟動)，則由于驗證數(shù)據(jù)(例如PCR值)會包含與RM本身相同的信息，因此僅發(fā)送在此次本地驗證進程中所用的RM就足夠了。因此最小確認可以不發(fā)送驗證數(shù)據(jù)，而是只發(fā)送在本地驗證過程中所用的參考值。在另一種方式中，不發(fā)送RM，而是當且僅當R頂具有唯一標識符時，僅發(fā)送對RIM的指示符。
[0267]最小確認的兩個條件包括:1)本地測量、驗證和強制(MVE)進程可信；2)用于在設備上存儲的R頂?shù)腞IM源可信。可以將本地MVE進程的驗證數(shù)據(jù)報告給外部實體進行評價。這用于信任的顯式建立?？蓪VE進程實現(xiàn)為使其不受攻擊。設備稍后報告RM的情況表明MVE進程可信。這用于信任的隱式建立。
[0268]為了評價所報告的RM的可信度，還可以發(fā)送由賣方、其他MNO、TTP和其他方所簽發(fā)的RHU正書。如果RBH正書的簽發(fā)者可信，則認為RM可信。如果所報告的任何一個RM不可信，則可采取措施，例如將設備置于隔離網(wǎng)中或列入黑名單。
[0269]可對RM和驗證數(shù)據(jù)的冗余進行調(diào)整，以增加效率。例如，可要求設備僅在特定情況下，或僅以特定頻率發(fā)送驗證數(shù)據(jù)。例如，如果PVM系統(tǒng)已經(jīng)檢測到了受攻擊的RM;新設備漫游至該運營商區(qū)域或SHO在一段時間內(nèi)未發(fā)現(xiàn)該設備。在另一示例中，可要求僅每進行“N”次確認發(fā)送一次驗證。
[0270]現(xiàn)在描述用于PVM的修正示例。修正或軟件更新都是設備持續(xù)服務所需的操作。設備需要修正的原因很多。除了正常的軟件升級維護、漏洞修正和增強以外，修正可以是集成在設備一般的安全進程中的部分。在確認過程期間，對設備上的軟件進行測量并驗證其完整性。將該測量值與位于TrE中的RIM進行比較。如果驗證失敗，則該代碼已被篡改，或RIM對該特定代碼庫出現(xiàn)是不正確的?？梢詥有拚^程來更新代碼庫或RM，以確保設備的正確確認。
[0271]如果對一個或多個組件的設備完整性檢查失敗，則這表明要么是這些組件受到了攻擊，要么是相應的可信參考值與設備上的代碼庫不一致。可以啟動修正過程，至少向CN表明設備不能對SeGW認證，同時還能有助于由網(wǎng)絡所啟動的對代碼庫或?qū)谒惭b的代碼庫的新可信參考值的更新?？赏ㄟ^SeGW在DMS與設備之間進行修正。
[0272]對于啟動任何修正，一些共同的安全要求都是適用的。這些要求是由發(fā)生失敗的安全啟動進程的階段所決定的。所考慮的最壞情況是在安全啟動的階段2所發(fā)生的失敗，該失敗表明建立了 TrE，但沒有與外部實體進行連接。因此，在這種情況下，設備不能在正常的啟動中請求修正。可安全地將額外的代碼庫，例如FBC，加載至TrE中，用來進行修正。這種進程的安全性是以以下為特征的:I)可將FBC完全地且無變化地加載至TrE中；2)TrE可安全地執(zhí)行該FBC ；3)與網(wǎng)絡實體(例如DMS)為進行修正所進行的通信會受到完整性和保密性的保護；和4)在整個過程中保護用于修正接入網(wǎng)絡的憑證?？商鎿Q地，不用將FBC加載至TrE。FBC可與TrE同時存在，例如，作為另一個用于單獨的修正目的的(可信)代碼庫。由于FBC存儲在安全的存儲器中，或受到HW安全秘密的保護，因此可產(chǎn)生對FBC的信任。這樣，TrE就不需要運行FBC。該FBC可以是獨立的，可直接運行，而不需建立TrE。
[0273]現(xiàn)在描述由設備啟動的修正示例。在設備確認的范圍內(nèi)，修正可以作為檢測到錯誤時，立即對設備進行隔離的替換方式。在自主確認的情況中，TrE是首先被驗證的部分。如果其驗證正確，則表明設備已經(jīng)達到了預定的安全啟動狀態(tài)。能夠這樣認為是因為TrE是可靠的，且存儲在TrE中的RIM是可信的。但是，這并不表明對于目前加載到設備中的特定版本的代碼來說，RIM是正確的。
[0274]現(xiàn)在描述由網(wǎng)絡啟動的修正示例。在自主確認的情況中，如果設備確認過程失敗，則可啟動FBC，對包含RM的主代碼庫觸發(fā)軟件更新。設備可發(fā)送IKEv2消息，該消息的通知負載表明設備正在執(zhí)行回退模式，需要立即進行修正。
[0275]對于半自主確認方法，修正過程不需要對軟件或可信參考值(TRV)進行全部更新。當設備通過了階段I和2的確認但階段3確認失敗時，可在IKEv2協(xié)議的通知負載或證書中將涉及失敗模塊的信息返回給PVE。如果PVE認為所述失敗模塊不重要，則可繼續(xù)進行確認和認證，同時所述失敗模塊被禁止/卸載。但是，如果所述失敗模塊重要，則PVE可向DMS發(fā)送信息，表明需要進行修正。
[0276]另一種情況是對于特定代碼庫，存儲在TRE中的RIM不正確。可將失敗的測量返回PVE，PVE中對信息的分析表明錯誤出現(xiàn)在RM中，且只有這些值才需要在TRE中安全地更新。
[0277]現(xiàn)在描述用于呼救信號和回退代碼的示例和實施方式。設備可具有回退代碼(FBC)圖，該回退代碼圖的目的是在設備完整性驗證失敗時，便于設備進行修正?？蓪⒃揊BC存儲在安全存儲器中，例如只讀存儲器(ROM)。如果本地設備完整性驗證失敗，則可調(diào)用該FBC0該FBC可至少包含用于與CN中負責對受影響的設備進行修正的實體進行通信所需要的所有必需功能、方法和證書。并且，F(xiàn)BC還可包含用于從網(wǎng)絡接收全部軟件更新的功能。還可考慮一個特殊的“修正” DMS0
[0278]設備和TrE可在設備完整性檢查失敗時，執(zhí)行以下修正指示過程。首先，TrE可啟動對可信碼進行操作，該可信碼稱為回退代碼(FBC)?？蓪⒃揊BC存儲在安全存儲器中，例如ROM。第二，F(xiàn)BC可以與預先指定的“修正”DMS建立安全連接。第三，F(xiàn)BC可以向DMS發(fā)送呼救信號，該呼救信號可包括設備ID。當接收到該呼救信號時，DMS就可知道該設備發(fā)生了例如完整性檢查失敗并請求進行維護?？蛇x地，DMS可在接收到該信號時啟動完整的固件更新過程，或執(zhí)行診斷以便執(zhí)行部分代碼/數(shù)據(jù)更新。
[0279]現(xiàn)在描述不需要RM的確認示例。不需要RM的確認可包括在負載TrE的控制下，將組件代碼安全發(fā)送至安全存儲器，例如安全存儲卡。不需要RM的確認還可以包括通過加密對摘要值進行替換，從而在普通存儲器中存儲加密組件，例如代碼。其還可以包括使用密鑰或加密密鑰進行加密，該密鑰可以是受TrE保護并與DMS共享的，該加密密鑰是由非對稱密碼算法得出的，其中，DMS和TrE可具有公共和私人密鑰對。不允許對加密代碼進行定向修改。由于對篡改數(shù)據(jù)進行解碼不產(chǎn)生意義，因此任何對代碼的操縱在解碼時都會被檢測出，例如在安全啟動的方式中。檢測這種變化可通過在加密代碼中包含摘要值來實現(xiàn)。可使用進一步的選擇，例如糾錯碼。
[0280]現(xiàn)在描述在確認過程中包含基于位置的信息的示例。一些設備可用于基于位置的信息占非常重要的地位的應用場景中，例如防盜、貨物追蹤、車隊監(jiān)控或監(jiān)視。通常設備可裝有全球定位系統(tǒng)(GPS)模塊來提供地理位置數(shù)據(jù)。安全啟動也可包括GPS模塊和組件，來確保對基于位置的信息進行可信的生成和存儲。還可額外地將位置信息安全地存儲在TrE安全存儲器中。之后可將位置信息包含在確認消息中。該消息可例如用于:如果所報告的位置與所需位置不符，則可通過OAM過程改變設備配置。如果設備報告了新位置，則可將其配置改變?yōu)槭蛊涫褂貌煌膮?shù)來連接網(wǎng)絡、觸發(fā)軟件事件(例如登錄、報告或關機)?？杉僭O位置信息由可信應用安全地進行操作。
[0281 ] 現(xiàn)在描述PVM在H (e) NB和M2M情況中的應用和實施方式，其提供了從通常PVM結(jié)構(gòu)到現(xiàn)有的標準化得網(wǎng)絡實體、協(xié)議和機制的映射。這兩種應用都顯示了特殊的安全需求。這兩種應用具有共同點i )隨著移動電話已經(jīng)被看做是成熟的經(jīng)典技術，對于存儲和處理敏感數(shù)據(jù)來說，所述設備不再是封閉、不可變的環(huán)境；和ii)通常，這些特殊設備受到移動網(wǎng)絡運營商(MNO)以外的相關方的控制，并僅通過間歇的和不安全的鏈路連接至核心網(wǎng)。
[0282]第一種應用涉及H(e)NB，即熟知的毫微微蜂窩基站。H(e)NB是小型的便攜式接入點，其向終端設備(例如移動電話)提供對3G網(wǎng)絡的連接。H(e)NB通常設置在室內(nèi)，或稱為主機方(HP)的相關方的屋內(nèi)。該HP在小型的指定地理區(qū)域內(nèi)，用作移動通信和服務的調(diào)解器。可使用該HP在目前無法接入的區(qū)域(由于不良的無線電狀況)(例如室內(nèi)或工廠的環(huán)境中)提供移動服務。由于H(e)NB可以作為對寬帶互聯(lián)網(wǎng)和移動網(wǎng)絡統(tǒng)一的接入點，因此其同時也是私人家庭或在家上班族(SOHO)這部分的選擇。
[0283]在H(e)NB使用環(huán)境內(nèi)，通過服務級別和使用協(xié)議將三個相關方，用戶——HP——ΜΝ0，聯(lián)系在一起。在本文中，H(e)NB存儲大量敏感數(shù)據(jù)，例如表現(xiàn)為移動網(wǎng)絡定制的HP認證數(shù)據(jù)、允許連接至H (e) NB的無線發(fā)送接收單元(WTRU)或用戶設備(UE)列表(該列表存儲為封閉用戶組(CSG))、和接入控制列表(ACL)。這些數(shù)據(jù)中的一些可專門用于HP和/或用戶。同時，需要對H(e)NB的位置進行控制，以保護移動網(wǎng)絡不受干擾，和防止對服務的非法擴展。
[0284]圖7表示在H(e)NB705、WTRU或UE710和運營商核心網(wǎng)絡730之間的示例通信環(huán)境。其引入了兩個網(wǎng)絡實體，一個負責安全，一個負責對H(e)NB進行服務。操作、管理和維護735 (OAM)是位于核心網(wǎng)回程中的功能，其向H(e)NB705提供遠程管理功能。特別是，其提供軟件下載和更新、無線電和其他參數(shù)設置、以及其他類似功能。安全網(wǎng)關(SeGW)740是H(e)NB705進入運營商核心網(wǎng)絡730的主要進入點，其主要功能是保護網(wǎng)絡730免受非法連接嘗試和從欺詐H (e) NB或假冒H (e) NB所發(fā)出的任何類型的攻擊。
[0285]第二種預期應用涉及M2M通信。M2M設備(M2ME)典型的例子是販賣和售票機。更高級的情況還包括，對綜合熱電廠的遙測、設備維護和設備管理等等。如果通過移動網(wǎng)將M2ME連接至備份網(wǎng)絡，則MNO能向M2ME的所有者提供增值服務，首先是通過空中(OTA)的管理。與H(e)NB類似，M2ME受到不同于MNO的相關方的控制。該相關方具有特定的與MNO不同的安全需求。H(e)NB和M2ME的安全性是重點。在這兩種情況中，其各自的威脅、風險和之后的安全需求是類似的。
[0286]可將威脅分為六個頂級組。組I包括攻擊證書的方法。這些方法包括對令牌和(弱)認證算法的暴力攻擊、物理入侵、邊信道攻擊。和惡意的主機方復制認證令牌。組2包括物理攻擊，例如向被操縱的設備中插入有效的認證令牌、啟動欺詐軟件(“重新刷機(reflashing)”)、物理篡改和環(huán)境/邊信道攻擊。組3包括配置攻擊，例如欺詐軟件更新/配置改變，HP或用戶的錯誤配置，對ACL的錯誤配置或攻擊。組4包括對設備的協(xié)議攻擊。這些攻擊威脅了功能性，并直指HP和用戶。主要例子包括在第一次接入網(wǎng)絡時的中間人(MITM)攻擊、拒絕服務(DoS )攻擊、通過利用工作的網(wǎng)絡服務的弱點來攻擊設備和對OAM及其流量的攻擊。組5包括對核心網(wǎng)的攻擊。這是對MNO的主要威脅。其包括模擬設備、在設備間開通流量隧道、對調(diào)制解調(diào)器/路由器中的固件進行錯誤配置以及對核心網(wǎng)的DoS攻擊。在H(e)NB的情況中，其還涉及以不允許的方式改變位置。最后，其包括使用惡意設備對無線接入網(wǎng)的攻擊。組6包括用戶數(shù)據(jù)和標識隱私攻擊，包括竊聽其他用戶的通用移動電信系統(tǒng)(UMTS)陸地無線電接入網(wǎng)(UTRAN)或演進型UTRAN (E-UTRAN)的接入數(shù)據(jù)、冒充其他用戶、向H(e)NB所有者公開用戶的網(wǎng)絡ID、冒充有效H(e) NB，和通過CSG提供無線電接入服務。
[0287]核心功能性需求對H(e)NB和M2ME來說是新的，其主要涉及對不同相關方的認證和在相關方之間功能和數(shù)據(jù)的分隔，即域分隔。特別是，對HP或M2ME所有者的認證應當與設備對網(wǎng)絡的認證相獨立。并且，必須保護HP的秘密數(shù)據(jù)不被另一方(即使是ΜΝ0)訪問。設備必須執(zhí)行對安全性敏感的任務，并同時對接入網(wǎng)和所連接的WTRU執(zhí)行安全策略。這必須能夠至少按半自主的方式來進行，以提供服務的連續(xù)性，并避免回程鏈路中不必要的通信。另一個重要的安全領域是分別由OAM或OTA進行遠程管理。設備需要安全地下載和安裝軟件更新、數(shù)據(jù)和應用程序。
[0288]這需要分隔認證地位，同時還要將對核心網(wǎng)的變動減到最小，從而重新使用標準的3G認證協(xié)議，例如可擴展認證協(xié)議-認證和密鑰協(xié)議(EAP-AKA)。至此所構(gòu)想的方法包括用于HP和/或M2M所有者的分離的認證載體。在前者中，可將其實現(xiàn)為所謂的HP模塊(HPM)，在后者中為受管標識(MID)。這兩者都可以是通用集成電路卡(UICC)(即3G用戶標識模塊(SM)卡)的假名。在M2M的情況中使用可拆除的智能卡產(chǎn)生了各種安全擔憂。一方面，需要避免必須交換這種智能卡的維護操作，例如用于更新或運營商變化，因為對于在地理上分散的大型M2ME隊列來說，這樣做花費很大。另一個最近需要慎重考慮的選擇是向設備中的安全環(huán)境下載AKA證書。一種該選擇所允許的使用真正TC技術的可能結(jié)構(gòu)是虛擬SM。
[0289]在任何情況下，安全性需求以及高級OTA或遠程管理，都需要M2ME和H(e)NB有特別的安全性特征?？蓪rE用于該目的。TrE需要安全地與系統(tǒng)其他部分進行交互。觀察TrE的接口很有意思，因為這些接口是TS的TCB與平臺剩余部分進行通信的通用模型?；旧?，在TrE的安全啟動進程中初始化所有TrE接口，因此認為其正確操作。TrE接口有兩種寬泛的安全類型。第一，有未受保護的接口。這些接口使得具有設備通用源的TrE免受篡改和/或竊聽，所述設備通用源被認為是不安全的。即使是未受保護的接口也可從其他安全措施中獲益，例如數(shù)據(jù)加密，或僅在TrE在例如安全啟動期間，對經(jīng)過接口的對端資源的代碼進行檢查后，才允許該接口可用。
[0290]第二，有受保護的接口。這些接口或使用安全協(xié)議或使用安全硬件，來對在其上運行的數(shù)據(jù)的完整性和/或機密性提供保護。如果使用安全協(xié)議，則其還可以提供認證和消息認證和/或機密性。
[0291]可在通信實體不對通信數(shù)據(jù)提供保護時，選擇未受保護的接口。可當需要對TrE與該TrE需要進行通信的另一資源之間的數(shù)據(jù)的完整性和/或機密性提供保護時，選擇受保護的接口。因此，TrE性能會有所不同。圖8表示了 H(e)NB內(nèi)的TrE示例，以及其可能連接的其他資源。這是最小化的配置，該配置包括計算并向SeGW發(fā)送H(e)NB設備認證所需參數(shù)的功能、進行H(e)NB確認的功能(包括在啟動時，對H(e)NB剩余部分進行碼完整性檢查)和最小加密功能(真實隨機數(shù)生成器)。對于認證，可認為TrE可邏輯包含HPM。
[0292]可以很容易地將通用PVM描述的結(jié)構(gòu)映射至現(xiàn)有H(e)NB結(jié)構(gòu)。其數(shù)據(jù)庫(V_DB和C_DB)及其管理組件對現(xiàn)有H(e)NB基礎結(jié)構(gòu)來說是新的。圖9A和9B同時表示了這兩種情況，通過SeGW的H(e)NB連接，和H(e)NB與HMS通過接口 I_hms_d的直接連接。[0293]圖9A 的 PVM 結(jié)構(gòu)或系統(tǒng) 900 包括 H (e) NB905,該 H (e) NB905 包括 TrE910。WTRU912(或用戶實體(UE))可通過1-ue接口 914與H(e)NB905進行通信。H(e)NB905通過I_h接口 915與H(e)NB網(wǎng)關(GW) 918進行通信，該H(e)NB網(wǎng)關包括SeGW920。通常，H(e)NB905與SeGW920之間的接口 I_h915可以是未受保護的，并可采用特殊措施來保證該信道的真實性、完整性和可選的機密性?？梢允褂肐_h915來在H(e)NB905與SeGW920 (從而與CN之間)建立鏈路。例如，SeGW920可以通過接口 1-aaa975與AAA服務器進行通信。運營商可以建立適當?shù)臏y量來保證接口的安全性。
[0294]SeGW920可以使用I_pve接口 922來在確認期間與PVE924進行聯(lián)系。PVE924可使用1-pve接口 922將確認結(jié)果發(fā)送給SeGW920。可將1-dms接口 930用于在H (e) NB管理系統(tǒng)(HMS) 935與SeGW920之間所進行的與設備配置有關的通信。PVE924可使用Ι-pd接口 932來與HMS935進行通信，反之亦然。可在設備管理過程中使用該接口 I_pd932，用于設備軟件更新和配置變化。
[0295]PVE920 使用接口 I_v926 和 I_d938 來從 V_DB940 中讀取 RM，HMS935 可使用接口1-v926和1-d938UC_DB950中讀取允許配置。接口 I_r928和I_c934可由PVE920用來(例如在V-DB940中丟失RM的情況下)與RIMman960進行通信，和由HMS935用來與CPman970進行通信。RIMman960和CPman970可分別使用接口 I_rdb962和I_cdb972來讀取、寫入和管理對數(shù)據(jù)庫V_DB940和配置策略數(shù)據(jù)庫C-DB950的確認。
[0296]圖9B表示了 PVM982，其中H(e)NB905可直接與DMS935連接。例如在回退模式情況下，在該模式中，H(e)NB905不能與SeGW執(zhí)行安全協(xié)議。在這種情況下，HMS935可通過接口 1-dms_d984 作為 H(e)NB905 的第一連接點，并通過接口 I_pve986 和 I_pd988 與 PVE924進行通信，以執(zhí)行確認，或至少獲知哪些組件在安全啟動中失敗。HMS935可根據(jù)該信息進行修正操作。
[0297]可以多種方式將使用PVE的確認直接映射至H(e)NB情況。由HMS或能訪問C_DB的適當擴展的實體(演進的HMS CeHMS))來執(zhí)行DMS功能。
[0298]對于基于策略的更新，C_DB提供了策略，能夠指明模塊的重要性和模塊的各個發(fā)布版本的互操作性，例如一些模塊對于操作來說是重要的，而一些不是。這有助于限制更新的大小，并提供補丁，而不是整個固件更新。最簡單的策略可以是將所有模塊都定義對H(e)NB操作重要，這樣就會執(zhí)行固件更新。
[0299]當模塊測量失敗時，eHMS檢查策略，以查找該模塊的危險程度，及其對模塊互操作性的影響。根據(jù)該檢查，建立可用補丁列表。該補丁可以集中或單獨地發(fā)送至設備，以用于應用。在其他情況中，每個傳輸單元都是受到完整性和機密性保護的。鏈路必須按順序發(fā)送數(shù)據(jù)包，且不能丟失。當接收到所有補丁時(例如由eHMS通過終止數(shù)據(jù)包或標記來指示)，如果需要的話，設備向eHMS發(fā)送所接收的補丁列表，以及其測量值，以驗證更新信息，或如果由eHMS發(fā)送集中的和單獨的補丁測量，則設備對補丁執(zhí)行本地驗證，并開始應用。在應用該補丁之后，系統(tǒng)在正常模式中啟動，開始設備確認過程。
[0300]也可進行以下過程，每當制造商發(fā)布新的固件版本時，使eHMS向設備發(fā)送更新通知，設備使用ECB進行啟動，并向eHMS發(fā)送測量。該eHMS提供補丁或完整的固件更新，之后進行相同過程。
[0301]在非基于策略的更新的情況中，一旦發(fā)生任何測量失敗，HMS都通過安全鏈接發(fā)送完整的新固件。設備對該固件進行驗證，將其應用，并在正常模式中啟動。
[0302]在處于之前已知的良好狀態(tài)的情況中，如果H (e) NB支持存儲系統(tǒng)狀態(tài)，則eHMS可在撤回測量失敗的補丁時，要求H(e)NB返回之前已知良好狀態(tài)。可使用該方法來將系統(tǒng)返回出廠狀態(tài)。該之前已知的良好狀態(tài)可以是經(jīng)PVE、eHMS或S(e)GW證明的狀態(tài)。
[0303]H (e) NB可返回之前已知的良好狀態(tài)，可對系統(tǒng)狀態(tài)提供完整性保護，可對之前所存儲的系統(tǒng)狀態(tài)提供恢復操作，以及可能需要在設備受攻擊的情況下保護該恢復操作。
[0304]現(xiàn)在描述對通過公共互聯(lián)網(wǎng)連接的設備進行確認的示例。對于通過不安全的初始鏈路，例如公共互聯(lián)網(wǎng)，分別連接至SeGW、CN的設備，需要采用特殊的要求來確保確認初始步驟的安全。這些特殊要求同時還可用于H(e)NB類設備，這類設備請求從SeGW建立這類連接，并通過該連接進行確認。盡管這里描述了網(wǎng)絡實體的H(e)NB對等物(counterpart)(例如HMS而不是PVM的普通實體)，但是應當清楚，一些方法和裝置只能用于非H(e)NB的設置中。通常，需要將確認和認證與初始連接的前幾步相綁定，或甚至綁定到相同的數(shù)據(jù)結(jié)構(gòu)中?，F(xiàn)在描述兩種方式來將確認和認證與專門協(xié)議，例如TLS和IKEv2進行綁定。
[0305]IKE、ISAKMP的傳輸協(xié)議定義了大量可用的證書簡檔，該簡檔允許使用正式域名(FQDN)作為ID?？蓪⒃O備證書和TrE證書分開保存。但是，也可將TrE證書放入設備證書中。如果TrE具有單獨的ID(TrE_ID)，則可使用FQDN，但是可由制造商來對TrE進行標識，而不是運營商域名。
[0306]在IKE_SA_INIT階段，并且在IKE對話的第I階段完成了 Diffie-Hellmann密鑰交換時，一種方法可使SeGW發(fā)送第一認證交換消息來請求Dev_CERT，該消息包含CERTREQ負載。之后，設備在下一消息中使用兩個CERT負載進行回復，一個使用Dev_CERT，一個則是TrE_CERT。在這種情況下，SeGW延遲Dev_CERT驗證，直到PVE已經(jīng)驗證了 TrE_CERT和評價了確認數(shù)據(jù)。之后，繼續(xù)進行認證。在回復僅包含Dev_CERT的情況下，SeGff回到AuV。
[0307]如果各個ID用于不同的操作目的，則Dev_CERT和TrE_CERT之間的區(qū)別是有利的。例如，運營商可能向設備分配了網(wǎng)絡地址，例如IP地址，Dev_CERT可對其認證，并從該地址直接建立IPSec通道。而一些類型的網(wǎng)絡地址可能不適用于TrE_CERT。因此，設備中兩個ID是有幫助的。SeGW/PVE基礎結(jié)構(gòu)的進一步任務是通過根據(jù)TrE_CERT，應用執(zhí)行PVM和輔助認證，來為Dev_CERT交換服務。
[0308]IKE認證消息可攜帶任何數(shù)量任何類型的負載。在每個負載的報頭，該消息可包含“下一負載類型”字段。這樣，就可在一個ISAKMP消息中發(fā)送整個負載鏈。這可用于將證書分隔至一個或多個初始IKE會話第2階段的ISAKMP消息的負載字段內(nèi)。在圖10中表示了設備1005、SeGW1010和PVE1015之間的示例進程1000，該過程使用IKE會話，將用于TrE和設備認證的證書完全分隔。從設備1005向SeGWlOlO發(fā)送消息，該消息包含(TrE_Cert、VAL_DAT) (I)。SeGWlOlO對所獲得的TrE證書(TrE_Cert)進行驗證(2)。如果TrE_Cert驗證成功，則SeGfflOlO向PVE1015發(fā)送確認數(shù)據(jù)消息(VAL_DAT) (3)。PVE1015對設備1005進行確認(4)，并向SeGW1015通知成功(5)。SeGW1015向設備1005發(fā)送證明請求(CERTREQ)(6)。響應于所接收的證明請求,設備1005向SeGWlOlO至少發(fā)送設備證明，(Sig_Dev(Dev_ID)、Dev_Cert) (7)。SeGWlOlO 對 Sig(Dev_ID)進行驗證(8)。如果驗證成功，則向 AAA 基礎結(jié)構(gòu)發(fā)送設備證明(Dev_Cert)，該AAA基礎結(jié)構(gòu)回復該設備是否已知。根據(jù)本實施方式，只有通過發(fā)送由TrE所簽名的確認數(shù)據(jù)以及由TrE_CERT所證明的標識而被認為確認可信的設備，才能進行設備認證。這在SeGW后對網(wǎng)絡組件提供了擴展保護，有助于減輕DoS攻擊。
[0309]在另一示例中，用于補充數(shù)據(jù)(supplemental_data)的TLS握手消息對TLS問候握手消息定義了擴展，該擴展能夠在TLS握手中發(fā)送應用特定數(shù)據(jù)，例如來自PVM的確認消息。該補充數(shù)據(jù)不能由TLS協(xié)議使用，而是由應用程序使用，例如PVE確認引擎。有可能只允許存在一個補充數(shù)據(jù)握手消息，而接收到多個就可看作失敗。可將所攜帶的數(shù)據(jù)的類型和格式指定為補充數(shù)據(jù)類型(SupplementalDataType),并可對發(fā)送方和接收方已知。
[0310]在一種方式中，可以執(zhí)行雙握手，從而對補充數(shù)據(jù)握手消息中所攜帶的執(zhí)行PVM數(shù)據(jù)提供保護。并且需要確保在任何一方提供補充數(shù)據(jù)信息之前，雙方經(jīng)過了相互認證。
[0311]可以定義新的補充數(shù)據(jù)類型來承載執(zhí)行PVM確認消息。則H(e)NB可將第一個TLS握手用于與SeGW進行相互認證。這樣可使用第一個TLS會話來保護第二個握手，并在補充數(shù)據(jù)字段中向SeGW發(fā)送確認數(shù)據(jù)。
[0312]在另一種方式中，可通過在第一個握手消息中發(fā)送補充數(shù)據(jù)來在一次握手交換中發(fā)送確認數(shù)據(jù)，而不是兩次。對于使用TLS會話票據(jù)(session ticket)擴展的確認連接，SeGW可在確認中使用TLS擴展，來將確認結(jié)果存儲在TLS會話票據(jù)中，該TLS擴展允許服務器向客戶發(fā)送會話票據(jù)，用于恢復會話和保存每個客戶的會話狀態(tài)。
[0313]在PVM中可使用這種會話票據(jù)用于平臺管理。當特定失敗組件列表的確認失敗時，SeGff從PVE接收該通知，并生成會話票據(jù)。使用128位的AES對稱密鑰對該票據(jù)加密，該密鑰不對H(e)NB公開，且該票據(jù)的完整性受到基于哈什的消息認證碼(HMAC)的保護。這樣，該票據(jù)就不會被H(e)NB修改，且當由H(e)NB發(fā)送時，其他網(wǎng)絡實體能夠認出該票據(jù)。之后，TrE可將該票據(jù)安全存儲，并在新的TLS會話中使用該票據(jù)用于平臺管理，而不需要例如再次發(fā)送確認數(shù)據(jù)。SeGW還可決定會話票據(jù)的存在時間。
[0314]之后可將AES票據(jù)加密密鑰放在T_PVM中以進一步使用，或直接發(fā)送給其他實體。之后，可以將該密鑰以及例如票據(jù)時間戳和詳細的確認結(jié)果，從PVE發(fā)送至HMS。通過使用該TLS會話票據(jù)，H (e) NB可直接建立用于進行平臺管理的安全連接。這將依賴于H (e) NB及時地跟蹤平臺管理，并在票據(jù)超期前聯(lián)系HMS。
[0315]當H (e) NB已經(jīng)通過使用會話票據(jù)所建立的連接與HMS完成修正時，可將會話票據(jù)用于重新確認。第一步是使用舊的票據(jù)從H(e)NB向SeGW建立新的TLS連接。之后，SeGW可控制該票據(jù)是來自實際已與HMS完成了管理周期的H(e) NB。在管理完成后，SeGW查找并將該票據(jù)數(shù)據(jù)與HMS所返回的T_PVM進行比較。如果找到正確的T_PVM，則可接受該使用TLS票據(jù)的重新確認嘗試，從而例如防止受到使用TLS票據(jù)為重放而發(fā)起的DoS攻擊。TLS票據(jù)可被接受用于重新確認，否則會認為其超期，這是因為與HMS所進行的修正過程會花很長時間。完成該操作不會對安全造成較大損失，因為SeGW具有帶時間戳的T_PVM可用于比較。
[0316]現(xiàn)在描述進行自主確認(AuV)的PVM的示例。AuV方法不向SeGW傳送任何確認數(shù)據(jù)，因此不需要為設備的初始網(wǎng)絡連接而對現(xiàn)有協(xié)議進行任何改變。因此，在設備安全啟動期間，PVM系統(tǒng)獲知關于驗證結(jié)果的任何事。唯一所傳輸?shù)脑O備專用信息是Dev_ID。
[0317]AuV限制了根據(jù)平臺確認結(jié)果來管理設備的可能性。特別是，沒有直接的方法來區(qū)分出初始向網(wǎng)絡進行認證的設備，和在更新后為重新確認而執(zhí)行AuV的設備。如果設備管理是基于AuV的，則需要在網(wǎng)絡中有數(shù)據(jù)庫，用于存儲設備狀態(tài)歷史?，F(xiàn)在描述的示例方法能夠有效地根據(jù)AuV至少執(zhí)行基本設備管理。
[0318]現(xiàn)在描述用于僅能進行AuV的設備的H (e) NB修正的示例。僅能進行AuV的設備執(zhí)行安全啟動，該安全啟動當且僅當設備完整性驗證成功時，才允許設備執(zhí)行設備認證過程。如果任何組件的完整性檢查失敗，則可認為該設備的完整性檢查失敗。但是，通過使用FBC圖像，該設備可聯(lián)系指定的HMS，以進行設備修正。
[0319]一旦與修正HMS的連接建立，則可替換H(e)NB的正常代碼圖像和/或可信參考值。當修正過程完成時，H(e)NB應重啟，并再次重新開始完整性檢查過程。
[0320]如果一組預定條件滿足，則PVM可使用FBC。一個示例條件是FBC被安全的存儲在設備中。另一條件是可在安全失敗的情況下加載和啟動FBC。而另一個條件是指定H(e)MS的地址安全地存儲在FBC圖像中。而另一個條件是FBC可向指定H(e)MS發(fā)送呼救信號。該信號可包括設備ID，且該消息可受到密鑰的完整性保護，該密鑰作為FBC的一部分安全地存儲。進一步的示例條件是當接收到該信號時，H(e)MS可確定設備的完整性檢查失敗，需要進行維護。而另一個條件可以是FBC可包含的功能可實現(xiàn)由網(wǎng)絡觸發(fā)的完全代碼重建。另一個條件可以是FBC可包含的功能可實現(xiàn)由網(wǎng)絡發(fā)起的TRV替換。
[0321]圖1lA和IlB表示的示例方法用于在完整性驗證失敗后，由FBC所實現(xiàn)的設備修正。RoTIIOO檢查呼救標記(I)。如果該標記為空，則RoTIIOO檢查TrE1105的完整性
(2)。如果設置了該標記，則RoTIIOO加載FBC(3)。如果完整性檢查成功，則RoTIIOO加載TrE1105(4)。如果完整性檢查失敗，則RoTIIOO設置呼救標記，并重啟(5)。一旦加載了正常代碼，則TrE1105對正常代碼的完整性進行檢查(6)。如果完整性檢查成功，則TrE1105加載正常代碼圖像(7)。如果完整性檢查失敗，則TrE1105設置呼救標記并重啟(8)。如果RoT已經(jīng)加載了 FBC，則由FBC啟動，向HMS發(fā)送用于修正的呼救信號(9)。
[0322]現(xiàn)在描述使用AuV進行修正和配置改變的基本方法的示例。在AuV期間，唯一發(fā)送給SeGW，且可能在平臺管理中使用的單獨信息是設備標識。因此，一個實施方式中可向設備分配多個標識，以在AuV中使用該標識來對(有限數(shù)量的)狀態(tài)(例如組件完整性驗證失敗)進行通知。在另一個實施方式中，可使用組ID來通知驗證結(jié)果，該組ID不是專用于任何一個設備的。可根據(jù)安全啟動進程的步驟來將管理標識分組。例如，DevM_ID3b用于通知階段3b失敗，DevM_ID3a用于通知階段3a失敗，和DevM_ID2用于通知階段2失敗。階段I失敗不能通知，因此此時設備缺乏通信能力。
[0323]在另一 AuV使用情況的例子中，設備可在失敗和執(zhí)行回退代碼后嘗試連接HMS，作為下一步操作。
[0324]在階段2中某一個或多個組件的失敗并不能表明該設備不能進行通信。應將該階段理解為屬于特定類型的組件分類。只要在階段2中加載了最關鍵的組件，設備就能夠?qū)⑵錉顟B(tài)和失敗組件發(fā)送給PVM系統(tǒng)。這種情況是如果設備上有策略管理器，該策略管理器由HMS維護，并提供標準框架，在該標準框架下都能進行連接。
[0325]為了安全性，必須將DevM_IDn和相關認證數(shù)據(jù)(例如私人密鑰)保護好，否則攻擊者會進行欺詐攻擊，從而破壞管理過程。這是十分危險的威脅，因為管理ID對大量設備都是相同的。一種解決辦法是僅使用該信息來設計平臺管理過程。通過將第一確認綁定到重新確認，能夠為唯一設備通知管理進程的成功，該第一確認通知某些未知標識的設備的失敗。確定有多種方法可執(zhí)行該操作。在一個示例中，在設備已經(jīng)認證了管理標識中的一個之后，SeGW運行補充協(xié)議，設備必須在該補充協(xié)議中對原始Dev_ID進行認證。在另一種方法中，通過交換特定秘密，設備和PVM系統(tǒng)以及特別是SeGW建立了管理會話，該管理會話覆蓋第一確認過程和第二重新確認過程。
[0326]現(xiàn)在描述補充認證協(xié)議的示例。設備和SeGW已經(jīng)完成了對設備的第一認證協(xié)議，設備在該第一認證協(xié)議中對其管理標識DevM_IDn中的一個進行認證。其中，假設它們已建立了加密的和經(jīng)認證的通信會話。之后，設備可只發(fā)送Dev_ID和用于該Dev_ID的認證數(shù)據(jù)。例如，可通過該建立的安全信道來發(fā)送簽名消息和公共密鑰證書。這就確保了沒有其他方知道該請求管理的設備的標識，也不會使用該信息來破壞管理過程，即，不會在重新確認前使設備無效，或假冒該設備。
[0327]SeGW將DevM_ID和Dev_ID發(fā)送給PVE，PVE將其插入需要管理的設備列表。之后，PVE將所需的設備管理操作通知給DMS，例如“安裝階段2回退代碼”。DMS通過之前由SeGW所建立的安全信道，將相應代碼下載至設備。在正常PVM中，之后系統(tǒng)啟動設備的重新確認。
[0328]當管理成功時，之后設備在AuV中對其原始Dev_ID進行認證。SeGW將其通知給PVE, PVE在重新確認列表中找出該Dev_ID，并將其刪除。否則，設備可再次對管理ID進行確認，也將該管理ID找出，并根據(jù)策略進行進一步操作。
[0329]現(xiàn)在描述建立管理會話的示例。該實施方式與其他實施方式的不同之處在于PVM對唯一的單獨設備進行管理?？稍谠O備與SeGW之間的通信協(xié)議中建立該管理會話。這種方法的作用是實際通過建立假名，使設備標識對PVM系統(tǒng)保持未知。
[0330]在正常的協(xié)議執(zhí)行中，可能會限制協(xié)議建立這種永久秘密的能力。例如，公共密鑰建立協(xié)議，例如Di f f i e-He I Iman (D-H)，滿足一種稱為聯(lián)合密鑰控制的屬性，使得所建立的密鑰依賴于雙方。也就是說，雙方向協(xié)議中插入(偽)隨機信息，以在每次執(zhí)行中產(chǎn)生不同密鑰。覆蓋了多方的會話執(zhí)行不能使用這種協(xié)議來建立。
[0331]因此，SeGff和設備必須在特殊的協(xié)議中建立秘密，例如通過使用發(fā)問(challenge)-響應。可由設備或SeGW引起發(fā)問，該響應必須滿足,在第二個執(zhí)行(即重新確認)中的第二個回復與第一輪中的回復相同。在簡單的實施方式中，設備只需在重新確認中示出從SeGW所獲的現(xiàn)時，而SeGW在表中查找該現(xiàn)時。因此該現(xiàn)時為假名?？墒褂酶鼜碗s的加密協(xié)議。
[0332]之后，可按上述來進行重新確認。但是，其區(qū)別在于，在此方法中，SeGW由于操作原因而對重新確認的設備的信息進行維護，因為該信息會在SeGW與設備間的重新確認所用的協(xié)議執(zhí)行中被使用。
[0333]現(xiàn)在描述用于H(e)NB的基于OMA設備管理(DM)的結(jié)構(gòu)的示例。OMA DM是由開放移動聯(lián)盟(OMA)設備管理(DM)工作組和數(shù)據(jù)同步(DS)工作組所聯(lián)合規(guī)定的設備管理協(xié)議。OMD DM是為小型移動設備而形成的，例如電話或PDA。其不支持設備與DM服務器之間的寬帶有線連接，而僅支持短距離有線連接，例如USB或RS232C，或無線連接，例如GSM、CDMA或WLAN。但是，其可用作H(e)NB(尤其在將自身作為與之連接的CSG和非CSG WTRU的基站的同時，還將其自身作為核心網(wǎng)的WTRU的H(e)NB)的設備規(guī)定和管理協(xié)議。
[0334]OMA DM所用于支持的使用情況，例如提供，包括首次設備配置和實現(xiàn)或禁止特征、設備配置更新、軟件升級和診斷報告和查詢。雖然設備可以可選地執(zhí)行這些特征中的一些或全部，但OMA DM服務器端可支持所有這些功能。
[0335]可將OMA規(guī)范優(yōu)化為對連接受限的小型設備支持上述特征。其還可使用認證支持集成的安全性(例如通過使用類似EAP-AKA這樣的協(xié)議)。
[0336]OMA DM使用XML (或更準確地，SyncML的子集)來進行數(shù)據(jù)交換。這可用于提供一種標準化同時靈活的方式，來為了確認的目的，而為軟件模塊或H(e)NB的功能定義和傳輸屬性。
[0337]在DM服務器與客戶端之間進行設備管理，該DM服務器例如是設備的管理實體，該客戶端例如是被管理的設備。該OMA DM支持傳輸層，例如WAP、HTTP或OBEX或類似傳輸。DM通信由DM服務器通過使用通知或報警消息，采用任何可用方法(例如WAP推入或SMS )來異步啟動。一旦在服務器和客戶端之間建立了通信，則可交換消息序列，以完成指定的DM任務。
[0338]該OMA DM通信基于請求-響應協(xié)議，其中，通常由DM服務器發(fā)出請求，而客戶以回復消息作為響應。服務器和客戶都是記錄狀態(tài)的，即在內(nèi)建的認證過程之后，可出現(xiàn)由于特定順序而進行交換的任何數(shù)據(jù)。
[0339]由于DM通信可由DM服務器來啟動，因此通過DM執(zhí)行PVM可能需要基于服務器查詢的方法來進行確認。例如，可以采用使用了 IKEv2的設備認證過程，該過程可由設備啟動?？煽紤]將多種不同消息類型作為確認數(shù)據(jù)的承載。例如，可在失敗軟件模塊或設備功能列表中發(fā)送。在另一示例中，可從設備向服務器發(fā)送管理報警消息。可替換地，還可考慮通用報警消息(在來自設備或服務器的至少一個管理報警消息傳輸之后，該通用報警消息只能從設備發(fā)送至DM服務器)的使用者。這些消息(包括報警消息)可使用SyncML格式，該格式在指定內(nèi)容和用于該內(nèi)容的元數(shù)據(jù)方面具有靈活性。這可用于確認信息傳輸。DM還可支持分段數(shù)據(jù)傳輸，這可用于軟件更新，其中更新的大小可能很大。
[0340]雖然最早的DM通信必須由DM服務器來啟動，但是之后的通信可由DM客戶使用繼續(xù)會話來啟動。DM客戶(例如H (e) NB或M2ME)的這種能夠啟動會話中的通信的能力可用于由設備啟動的任務，例如由設備啟動的重新確認或由設備啟動的確認消息傳送。
[0341]現(xiàn)在描述在認證證書中綁定確認的示例。在認證證書中綁定確認能夠?qū)崿F(xiàn)確認和認證的結(jié)合，從而自動將設備的認證ID與確認綁定。之后，將確認消息放在認證證書的附加字段中。例如，通過使用IKE協(xié)議，可以選擇地將這種驗證數(shù)據(jù)放在通知負載字段中。
[0342]如果驗證數(shù)據(jù)存儲在認證證書內(nèi)，則每次設備配置改變時，都必須發(fā)布新的合并的認證/確認證書。必須由SeGW來控制生成該證書，因為SeGW是負責為PVM目的進行Dev_ID認證的實體。這可至少以兩種方式來執(zhí)行。第一，SeGW或從屬實體可在從DMS接收到更新的Clist之后，生成該新證書。第二，設備可自己生成該證書，并將其發(fā)送至SeGW和PVE，由SeGW對其簽名，并將其發(fā)送回設備。
[0343]SeGff可在成功進行某種重新確認之后，結(jié)束該過程(或者生成并發(fā)送新證書，或?qū)τ稍O備所生成的新證書進行應答)。這是為了向PVM系統(tǒng)確保新配置實際到達了設備。
[0344]由于當設備配置變化時可能會需要新證書，因此該周期涉及CN中的全部三個實體及設備。DMS觸發(fā)配置變化(例如對軟件和/或參數(shù)的更新)，并將新的所需狀態(tài)保存在策略數(shù)據(jù)庫C_DB中。在將該變化應用至設備后，需要進行重新確認。[0345]在示例情況中，設備應用該更新并執(zhí)行重新確認。設備可使用新軟件，但不能使用新證書，直到完成了重新確認(特別是對成功的更新進程的)。此時，設備使用舊的證書來運行新的軟件配置，該舊證書與設備的實際配置不相匹配。響應于此，向設備提供新證書用于設備認證；當且僅當已經(jīng)應用了更新時提供；且需要確保在沒有應用更新時，不能使用該證書。
[0346]現(xiàn)在描述撤回設備認證證書的示例。如果在設備認證期間，SeGW判斷需要撤回該設備所發(fā)出的用于進行設備認證的設備證書，則SeGW可向設備指示由于證書撤回而導致設備認證失敗，并之后將該設備從網(wǎng)絡維護的白名單中刪除，或反之，加入到網(wǎng)絡維護的黑名單。設備在接收到該指示時，就可知其證書已被撤回，且其標識已從白名單中移除，或反之，加至黑名單中。之后設備可執(zhí)行操作，將其自身重新建立為網(wǎng)絡中的有效實體。
[0347]如果設備ID失效，設備證書過期或發(fā)出H(e)NB設備的由可信第三方運營商授權的實體及其相關證書請求網(wǎng)絡撤回證書，則SeGW可將設備證書撤回。
[0348]現(xiàn)在描述基于證書的確認基本方法的示例。綁定證書是簽名數(shù)據(jù)組。其由發(fā)出者、SH0、或其SeGW或負責管理證書的等同實體進行簽名。證書中的簽名數(shù)據(jù)至少包括Dev_ID、用于認證和確認的設備公共密鑰和Clist。
[0349]該證書可在確認和認證的合并消息中發(fā)送給SeGW。后者是(部分)由設備使用其私人密鑰進行簽名以用于認證和確認的消息。該消息可包含其他數(shù)據(jù)，例如時間戳和/或現(xiàn)時，用于防止重放。SeGW檢查證書和消息的簽名，并按正常過程進行確認。
[0350]現(xiàn)在描述證書交換的示例方法。通?？梢圆捎脙煞N方式。將其稱為證書前交換和證書后交換。其區(qū)別在于重新確認使用舊的還是新的證書。這兩種方式都確保自動執(zhí)行所有所需步驟，即，要么全部執(zhí)行，要么全都不執(zhí)行。起始狀態(tài)是設備使用舊證書運行舊配置，結(jié)束狀態(tài)是新設備配置和新設備證書。可能需要由獨立TTP或制造商來創(chuàng)建、管理和控制認證證書和R頂證書,從而設備可在多個網(wǎng)絡中使用，而不是將其固定在一個運營商上?？商鎿Q地，新設備證書可由例如開放移動聯(lián)盟(OMA)進行處理，以用于設備管理(DM)，可將其擴展為包含證書。
[0351]在證書前交換方法中，更新包括新證書，因此，在更新完成前證書進入設備。當應用更新后，設備使用新證書進行重新確認。在CN中使用合適的存儲器和數(shù)據(jù)結(jié)構(gòu)將該設備標記為“正在進行更新”。例如，在認證數(shù)據(jù)庫中設置標記。另一種方法是使用確認令牌T_PVM。
[0352]現(xiàn)在描述證書前交換流的一個示例。如標準PVM中一樣，DMS將更新和/或改變的組件發(fā)送至設備。之后DMS向SeGW發(fā)送新的Clist。DMS向SeGW傳遞T_PVM。這時，SeGW(從而PVM系統(tǒng))進入狀態(tài)，其中其等待設備對新配置進行重新確認。SeGW收集需要的信息(Clist、DeV_Id、設備公共密鑰等)，并生成新設備證書。之后，SeGW將該新證書發(fā)送至設備，之后結(jié)束與設備的通信會話。
[0353]現(xiàn)在，SeGff具有從DMS所獲得的T_PVM，并從而知道應等待設備的重新確認。其在內(nèi)部重新確認列表中存儲所有用于這樣的設備的T_PVM。假設設備正確安裝了更新和新證書，則進行以下進程。設備啟動重新確認，在確認消息中發(fā)送新證書。SeGW通過驗證簽名數(shù)據(jù)和設備證書來對設備進行認證。SeGW在重新確認列表中查$T_PVM。進行重新確認，其中使用來自之前的確認的T_PVM (且不再生成新的)來維護PVM系統(tǒng)狀態(tài)。在SeGW處而不是PVE處進行該步驟和之前步驟，否則SeGW會自動生成新令牌。因此為SeGW進行重新確認列表維護。
[0354]如在標準PVM中一樣，在多輪重新確認中連續(xù)使用T_PVM有助于檢測重復出現(xiàn)的更新失敗和其他形式的性能異常。
[0355]在進一步實施方式中，TrE具有可信更新服務，該服務允許HMS向設備發(fā)送更新，之后在安全可信的進程中應用該更新?？梢砸蕾嚢踩珕觼泶_保TrE中的更新服務的完整性。當HMS使用新更新時，其可向SeGW發(fā)送令牌，該令牌包含新更新的設備配置。之后，SeGW可為設備創(chuàng)建新認證證書，并將其附加在令牌上，將該令牌發(fā)回HMS。HMS包含新證書，以及用于設備更新服務的更新數(shù)據(jù)。該數(shù)據(jù)包可為TrE加密，并由HMS簽名?？尚鸥路战邮赵摳聰?shù)據(jù)包，驗證簽名，解密數(shù)據(jù)，應用更新，并在安全存儲器中存儲新證書。之后，TrE向HMS通知更新成功。由于可信更新服務由安全啟動所保護，因此更新過程可信，從而不需要重新確認。根據(jù)更新的類型，可能需要重啟。在這種情況下，設備可使用新證書在SeGW進行認證。因此，HMS必須確保通知了 SeGW關于所要進行的重新確認。
[0356]在另一實施方式中，如果在設備上不存在可用的可信更新服務，則可將新證書與新軟件更新一起提供，這樣證書由密鑰加密，該密鑰與成功安裝更新相綁定。這種方法及其所涉及的問題還需要更多考慮。
[0357]在證書后交換方法中，更新可以不包括包含新設備配置的新證書。設備使用舊證書進行重新確認。在重新確認成功后，CN激活新證書，并將新證書發(fā)送至設備。由于可能沒有新配置來進行安全啟動，因此將新配置發(fā)送至設備，盡管此時設備還沒有新證書。
[0358]現(xiàn)在描述運營商RM屏蔽的示例?？梢允褂脽o線局域網(wǎng)(WAN)管理協(xié)議來用于設備的遠程管理。圖12表示簽名消息格式1200的示例圖，該消息格式允許從發(fā)布者向設備下載軟件數(shù)據(jù)包。該格式允許在一個簽名數(shù)據(jù)包中發(fā)送一個或多個文件，例如固件更新或配置數(shù)據(jù)包。接收設備能夠?qū)υ催M行認證，并包含安裝該內(nèi)容的所有指令。
[0359]報頭1205可包含格式版本和命令列表及負載組件的長度。命令列表1210包含可被執(zhí)行用于安裝數(shù)據(jù)包中所含文件的指令序列。簽名字段1215可包含數(shù)字簽名，由報頭和命令列表組成該數(shù)字簽名所簽發(fā)的消息數(shù)據(jù)。雖然所簽發(fā)的消息數(shù)據(jù)僅包含數(shù)據(jù)包報頭和命令列表，但是由于所有涉及負載文件1220的命令都包含文件內(nèi)容的哈什值，因此該簽名可確保整個數(shù)據(jù)包的完整性。
[0360]在運營商RM屏蔽的情況下，DMS對命令列表簽名，并將軟件更新數(shù)據(jù)包及其各自RM放在消息的負載中。之后，設備的TrE使用公共密鑰對DMS的簽名進行驗證?？稍谥圃旎蚺渲脮r，或由運營商信任的CA，使該公共密鑰為TrE可用。可將所有對公共密鑰進行驗證所需的根證書安全地存儲在TrE中。命令列表則包含安裝軟件的命令和用于使設備獲得RIM的命令。這向運營商提供了有效的方式對設備上的軟件和RM安裝進程具有完全的控制。在這種實施方式中，不會出現(xiàn)向設備顯式地傳輸RMc。
[0361]現(xiàn)在描述使用第二代碼庫進行修正的示例。安全啟動失敗，例如在通用PVM設備模型中階段2失敗，會在比TrE更大的范圍上產(chǎn)生問題，該問題是TrE用于向加載至正常操作空間的修正組件擴展信任時不可信。因此，為了啟動修正，需要調(diào)用FBC，但是需要在TrE內(nèi)部運行，以至少用于最重要的功能性加密和修正協(xié)議棧。
[0362]在特定情況下，可以從外部安全源，此處稱為FBC載體(carrier)，獲得FBC。這可由以下進程完成，該進程一部分在帶外，且可以要求人工參與，例如向H(e)NB設備插入智能卡。該過程可通過將第二安全組件(智能卡)用作FBC載體(該FBC載體安全存儲并保護FBC代碼)或通過在修正初始化過程中明確要求人工參與，來提供增強的安全性，以減輕簡單自動的DoS攻擊，并可按照約定定期的從HP中獲得。該外部載體FBC可以是保證設備簡單便宜、TrE簡單的措施。該外部載體FBC可承載FBC的可執(zhí)行二進制代碼，包括修正所需的所有秘密，當需要時，還可額外為FBC提供安全的操作環(huán)境。在設備位于遠程或難以接近的位置的情況中，不再適用使用單獨的FBC載體。此處所述的在三個實體之間建立信任的進程與之前所述的各種“可傳遞的信任”過程相類似。
[0363]以下過程可用于外部FBC載體，例如UICC、智能卡或具有其自己的處理單元的安全存儲卡。TrE是依賴方，其要求加載經(jīng)授權和認證的FBC代碼。另一方面，只要用于修正的憑證一直受到保護，向未授權方顯示FBC代碼風險就較小。因為要執(zhí)行帶外過程，TrE向FBC載體的認證不是太大問題，在該帶外過程中，TrE和設備實際并不完全可信。這也是載體不應向設備顯示用于HMS接入的憑證的原因?？赡苄枰@示FCB，但風險較小。
[0364]因此，可使用以下授權或通信順序。該帶外或人工參與的步驟只是為了表示特殊使用的情況，在其他方法中可使其自動化或集成，例如將FBC載體嵌入H (e) NB中。在這種基于回退代碼的過程中，通信可能會非常簡單，因此可將認證和授權結(jié)合在單個協(xié)議步驟中。
[0365]首先，階段I的啟動成功，階段2的啟動失敗。TrE停止，進入“等待FBC”狀態(tài)，并閃爍LED，或提供其他類似的失敗指示。用戶/HP插入FBC載體。在本實施方式中，F(xiàn)BC載體，例如諸如主機方模塊(HPM)的智能卡，通過使用特定物理接口來通知FBC載體的授權秘密的存在和/或提交，例如OTP或簽名現(xiàn)時，來將其自身向TrE授權。在TrE和FBC之間，建立安全關聯(lián)(SA)，即加密和受完整性保護的通信會話。之后，將FBC加載至安全環(huán)境中，該安全環(huán)境可由TrE或FBC載體或這兩種環(huán)境性能的任何結(jié)合來提供。之后，如果需要的話，可對FBC進行整體性檢查，之后對其加載并啟動。
[0366]在安全啟動后，F(xiàn)BC使用秘密向載體表示加載成功，并在TrE (FBC)與載體之間創(chuàng)建新的SA。用于修正的憑證留在載體中，但FBC包含用于HMS發(fā)現(xiàn)的數(shù)據(jù)。FBC聯(lián)系HMS。通過使用受智能卡保護的憑證，在智能卡和HMS之間建立端對端SA,該憑證依然完全對TrE(FBC)不可用。現(xiàn)在，HMS得知有效TrE(FBC)請求修正。智能卡將通信會話交給TrE(FBC)，TrE (FBC)向HMS展示其ID。HMS啟動修正過程。該授權秘密需要保護好，因為這類連接可用于多個設備，因此其破壞是災難性的。一種用于執(zhí)行授權的方法將受TPM保護的授權秘密(例如160位HW保護的值)用作獲得所有關系過程中所創(chuàng)建的。根據(jù)該實施，可直接從FBC載體啟動FBC，之后FBC載體必須提供安全可靠的操作環(huán)境。在這種情況下，甚至還可取代受攻擊的TrE。一個例子可以是當FBC載體包含安全組件時，由微處理單元和存儲器獨立操作FBC?？赏ㄟ^公共接口(例如USB、JTAG)將FBC載體連接至設備，并直接向設備內(nèi)的組件認證，之后取代受攻擊的組件和可能的TrE組件。在另一種方式中，如果使用了簽名代碼圖像，則FBC載體設備可取代包含簽名的圖像。
[0367]由于在一些情況中，由于TrE不是完全可信的被用于正確加載和操作FBC，且在多數(shù)情況下，其不能對加載至FBC載體中的FBC進行確認，因此需要進行一些安全增強，從而FBC載體必須在遠程代碼庫執(zhí)行中建立信任。例如，F(xiàn)BC載體可生成一次性秘密，并使用混淆方法將其嵌入FBC中?？商鎿Q地，載體可與FBC —起，或緊隨FBC之后，發(fā)送另一授權秘密，該秘密只能由成功啟動的FBC識別和使用。該秘密由成功啟動的FBC用于從TrE中受保護的空間獲得緊接著下一步通信中所用的通信秘密。
[0368]現(xiàn)在描述為回退代碼使用內(nèi)部并行碼庫的示例。內(nèi)部并行碼庫可包括觸發(fā)機制和實現(xiàn)修正所需的回退代碼庫。例如，H (e) NB可包含兩個代碼圖像，一個是正常模式，一個是回退代碼圖像(FBC)?？稍诟鱾€階段中對AuV和SAV都執(zhí)行正常模式調(diào)用。在階段I中，ROM中的RoT對TrE進行驗證。如果TrE有效，則可檢驗下一階段的組件。如果之后任何組件的完整性檢查失敗，則將代碼卸載回到TrE代碼的開端。此時，TrE可開始檢查回退(例如修正)代碼。如果回退代碼通過了完整性檢查，則將其加載并啟動。該回退代碼可包含設備管理(DM)碼的一些最小集合，用于與HMS建立連接。一旦與HMS建立了連接，則可標識出失敗的模塊，并將更新發(fā)送至HNB。在修正進程完成時，H(e)NB可重啟，并重新開始確認進程?？杀３只赝舜a尺寸較小，以促進與HMS進行通信。由于代碼可“回退”至TrE中，且使用回退代碼進行加載，因此可不需要觸發(fā)機制或寄存器。
[0369]現(xiàn)在描述另外一種形式的“混合(內(nèi)部/外部)碼庫”?？稍诶缟鲜霾⑿写a庫的情況中將FBC存儲在設備內(nèi)，但是，F(xiàn)BC在設備上是加密的，并受到完整性保護。不能使用TrE自身來對FBC解密，否則，受攻擊的TrE會導致FBC本身受到攻擊。該混合方案將用于FBC的解密和驗證密鑰存儲在外部安全組件(例如智能卡或nCC)上。在啟動失敗的情況下，TrE通知該失敗，并要求用戶/HP向設備中插入認證令牌，即智能卡。根據(jù)設備屬性，兩種選擇可用。在第一種選擇中，認證令牌只存儲密鑰內(nèi)容，并與TrE進行相互認證，在該相互認證之中或之后，TrE接收所需密鑰內(nèi)容。TrE對FBC執(zhí)行完整性檢查和解密，之后加載并啟動FBC0在另一種選擇中，對認證令牌進行改進，使其能自動對存儲在設備上的FBC進行驗證和解密，之后或者通過僅使用設備資源(例如，使用部分TrE來提供安全的執(zhí)行環(huán)境)，或者通過在該認證令牌自身內(nèi)部所提供安全的、可執(zhí)行FBC的執(zhí)行環(huán)境來執(zhí)行該FBC。這種方式能夠允許使用設備較大的存儲空間進行FBC存儲，還合并入了附加外部安全元素的安全性。
[0370]現(xiàn)在描述用于使用內(nèi)部順序碼庫的實施方式。設備管理協(xié)議可在遠程設備上定義用于安裝和改變軟件配置的協(xié)議和命令，并可包括“重啟”命令。其可以不包括獲知發(fā)送“需要修正”消息的設備。但是，通過將例如SAV的確認結(jié)果與設備管理協(xié)議相結(jié)合，HMS可使用設備管理協(xié)議來對軟件組件啟動重新安裝或重新設置，并之后發(fā)布用于重新確認的重啟命令。
[0371]可替換的，F(xiàn)BC能夠刪除或卸載部分正常代碼，只留下剩余的正常代碼，并啟動重啟，重啟之后進行重新確認?？蓪BC預先規(guī)定需要刪除或卸載的正常代碼的列表?？商鎿Q地，F(xiàn)BC可從外部安全組件(例如智能卡(例如HPM))獲得該列表?？商鎿Q地，F(xiàn)BC可從基于網(wǎng)絡的實體(例如H(e)MS)獲得該列表。
[0372]為了使該機制安全操作，設備上可能需要有可信應用程序，該可信應用程序可包含以下屬性:完整性受保護；在設備中安全地存儲；能在安全啟動失敗的情況下啟動；向HMS建立(安全)連接；能夠?qū)碜訦MS的軟件和命令上的簽名進行驗證；能夠?qū)υO備上的軟件進行安裝/卸載；以及能夠?qū)υO備需要修正進行報告。
[0373]可以使用可能冗余的第二碼庫來負責該應用程序。從上述描述和根據(jù)上述要求，該第二碼庫向設備中引入一些額外的冗余碼。在設備中正常、成功的安全啟動的情況下，可能會需要該碼庫所提供的所有特征。第二碼庫的所有特征都可在第一碼庫中存在。
[0374]另一種方式是用順序設計代替并行設計。這會涉及以下順序。一旦成功，RoT驗證并啟動TrE。之后,一旦成功,TrE對修正代碼進行驗證。一旦成功,TrE對剩余的軟件組件進行驗證。如果不成功，TrE存儲失敗模塊，并設置標記，表示設備需要修正。之后，TrE觸發(fā)設備重啟。一旦重啟，對修正代碼進行驗證后，TrE傳送對修正代碼的控制，并釋放失敗模塊列表。之后修正代碼可為設備修正進程使用該列表，并聯(lián)系HMS。
[0375]現(xiàn)在描述使用安全性策略屬性的SAV的示例。向PVE通知哪些模塊的內(nèi)部完整性檢查失敗可包括為H(e)NB的所有結(jié)構(gòu)和模塊建立所有SW模塊的標準化列表。也可生成安全性策略屬性(SPA)的標準化列表。該SPA可以是策略，該策略通知PVE如果特定SW模塊的完整性檢查失敗，應當采取怎樣的操作。PVE不需要知道其他有關該失敗模塊的信息。
[0376]可對SPA碼進行標準化，其可包括以下代碼?！?0”模塊失敗可表示網(wǎng)絡接入被拒絕。所有這種類型的模塊都會是在階段2中，但在階段3的模塊中也包含該碼可實現(xiàn)靈活性?！?1”模塊失敗可表示允許暫時網(wǎng)絡接入。如在修正部分所描述的，設備可使用該暫時網(wǎng)絡接入來進行修正，例如通過使用修正中心來修正失敗的SW模塊，且如果修正不成功，則可停止網(wǎng)絡接入?！?2”模塊失敗可表示允許網(wǎng)絡接入。這可以是指允許對失敗SW模塊進行修正的修正中心，并可在修正不成功時，保持網(wǎng)絡接入。“03”模塊失敗可表示允許網(wǎng)絡接入。其可刪除/禁止/隔離失敗的SW模塊，并且如果操作不成功，可停止該網(wǎng)絡接入?！?4”模塊失敗可指示允許網(wǎng)絡接入。其可刪除/禁止/隔離失敗的SW模塊，并且如果操作不成功，可保持網(wǎng)絡接入。“05”模塊失敗可表示允許網(wǎng)絡接入，并可忽略SW完整性失敗?！?6”可指示其他失敗。
[0377]可將單個SPA與H(e)NB中的每個階段3的SW模塊相關聯(lián)。則SW模塊的實際標識符可由H(e)NB的每個構(gòu)造和模型所有。在SAV中，H(e)NB已向SeGW發(fā)送了 H(e)NB_ID，網(wǎng)絡可使用該H(e)NB_ID來標識H(e) NB的構(gòu)造、模型和序列號。對于每個階段3完整性檢查失敗，H(e)NB在通知負載中放入其所擁有的SW模塊ID和相應的SPA。如我們現(xiàn)有的每個SAV機制一樣，該負載被轉(zhuǎn)發(fā)至PVE。
[0378]PVE檢查SPA，如果存在任何SPA=OO,則SeGW不被授權對H (e) NB準許接入。如果SPA=Ol或02，則觸發(fā)修正進程。PVE發(fā)送H(e)NB_ID和SW模塊ID。修正中心可使用H(e)NB_ID來對其所擁有的SW模塊ID進行交叉參考，這樣其可向H(e)NB下載正確的更新。
[0379]如果有任何SPA=03或04，則PVE可向SeGW發(fā)送適當?shù)闹噶?。如果有任何SPA=05，則H(e)MS或其他網(wǎng)絡組件可存儲用于管理目的的數(shù)據(jù)。
[0380]可選地，非00的SPA可能會涉及一些重啟/重新確認和ACK消息。SPA=OO與AuV的最終結(jié)果一樣，除非網(wǎng)絡現(xiàn)在具有一些關于不良H(e)NB的信息，且可采取管理操作?？蛇x地，可不通知PVE關于通過了完整性檢查的模塊。
[0381 ] 如果FBC支持基本通信，則可將PVM擴展為包括階段2模塊的失敗。SPA可以是包含SW模塊ID的對象的一部分。需要將其存儲在TrE中。不能將其作為SW模塊的一部分進行存儲，且在SW模塊的完整性檢查失敗的情況下，其不可信。
[0382]根據(jù)風險評價進程，分配給每個SW模塊的SPA與每個H (e) NB提供者一致，其作為SW棧的類型確定進程的一部分。一旦提供者與運營商建立了聯(lián)系，則向新SW模塊分配SPA就變得簡單。根據(jù)之前成功的類型確定，信任由所建立的提供者來分配適當?shù)腟PA。[0383]為了減少對H(e) NB結(jié)構(gòu)的SW結(jié)構(gòu)進行標準化的需求，H(e) NB的SW結(jié)構(gòu)可按碼塊的方式來定義，其中根據(jù)完整性檢查或可修正的內(nèi)容，來將該塊定義為最小原子塊或量。不可定義各個塊功能。例如，從完整性檢查的角度來看，所有的階段3SW可作為一個單獨的塊。可替換地，可將塊1:1地映射至實際的SW應用程序，或應用程序內(nèi)的敏感對象。可將SPA應用至SW塊。當由于01或02的SPA而調(diào)用修正中心時，其下載所需塊。塊ID可涉及賣方，其結(jié)構(gòu)可以不是標準化的。
[0384]如果在設備確認中使用了 SPA，則可將SPA安全地存儲在TrE中，并與SW標識符綁定。這可例如保證，不會為另一具有OO-SPA的組件重放05-SPA。因此，PVE能夠驗證所接收的SPA實際屬于H(e) NB中所加載的組件。
[0385]可使用由設備最早的初始網(wǎng)絡連接所啟動的登記進程來將SPA從設備安全地傳輸至C_DB，并存儲用于以后使用。之后，設備可以報告失敗組件的SW_ID，且PVE能夠從本地數(shù)據(jù)庫中取回相應的SPA策略操作。這可用于低帶寬連接的設備。
[0386]現(xiàn)在描述用于對SPA進行分組的實施方式。如果將SPA本地存儲在TrE中，則TrE可檢查所有失敗代碼及其SPA，對其進行處理，并發(fā)送更加概括的階段完整性檢查。失敗模塊及其SPA可包括表1中所示的情況。
[0387]
【權利要求】
1.一種執(zhí)行耦合到平臺確認實體(PVE)的無線發(fā)射/接收單元(WTRU)的確認的方法，該方法包括: 測量所述WTRU的至少一個預先指定組件的完整性測量； 獲取所述WTRU的所述至少一個預先指定組件的可信參考值； 使用位于無線發(fā)射/接收單元(WTRU)中的可信環(huán)境(TrE)執(zhí)行所述WTRU的所述至少一個預先指定組件的完整性檢查，并存儲完整性檢查結(jié)果；所述完整性檢查包括所述TrE比較所測量的所述至少一個預先指定組件的完整性測量與所述WTRU的所述至少一個預先指定組件的所述可信參考值； 使用所述TrE在所述WTRU上執(zhí)行安全啟動檢查，并存儲安全啟動檢查結(jié)果；所述啟動檢查確定所述至少一個預先指定組件是否達到安全啟動的狀態(tài)，所述啟動檢查結(jié)果包括當所述至少一個預先指定組件沒有達到安全啟動的狀態(tài)時的指示； 使用所述TrE基于所述完整性檢查結(jié)果和所述安全啟動檢查結(jié)果形成確認消息；以及 使用所述TrE將所述確認消息從所述WTRU轉(zhuǎn)發(fā)到所述PVE，所述PVE在所述WTRU外部。
2.根據(jù)權利要求1所述的方法，該方法還包括: 使用所述TrE分階段地執(zhí)行安全啟動，以確保在每個TrE組件的本地確認成功的情況下加載第一 TrE組件和第二 TrE組件； 在第一階段，經(jīng)由依賴于信任根(RoT)的安全啟動加載所述TrE組件；以及 在第二階段，加載所述TrE外部的第二組件，以允許與所述PVE的通信。`
3.根據(jù)權利要求2所述的方法，其中所述確認消息包括本地通過/失敗指示符，以作為在所述第一階段和第二階段期間所建立的完整性的測量。
4.根據(jù)權利要求1所述的方法，該方法還包括啟動回退代碼庫。
5.根據(jù)權利要求4所述的方法，其中啟動所述回退代碼庫包括觸發(fā)對包括主代碼庫的軟件更新。
6.根據(jù)權利要求1所述的方法，其中所述完整性檢查確定只有登記的組件被激活。
7.根據(jù)權利要求6所述的方法，其中通過加載至存儲器中來激活所述登記的組件。
8.根據(jù)權利要求6所述的方法，其中通過開始進入完整性證實狀態(tài)來激活所述登記的組件。
9.根據(jù)權利要求1所述的方法，該方法還包括在所述設備已經(jīng)完成了成功的網(wǎng)絡連接的條件下，執(zhí)行第二完整性檢查。
10.根據(jù)權利要求1所述的方法，其中存儲完整性檢查結(jié)果包括在受保護的存儲位置存儲完整性檢查結(jié)果。
11.根據(jù)權利要求1所述的方法，其中所述確認消息包括加密簽名的聲明。
12.根據(jù)權利要求1所述的方法，其中所述確認消息包括所述完整性檢查與之后的認證過程之間的綁定的證據(jù)。
13.根據(jù)權利要求1所述的方法，其中所述確認消息包括所述安全啟動檢查與之后的認證過程之間的綁定的證據(jù)。
14.根據(jù)權利要求1所述的方法，其中所述確認消息包括時間戳。
15.根據(jù)權利要求1所述的方法，其中所述確認消息包括第一時間戳和第二時間戳，所述第一時間戳在所述完整性檢查和所述啟動檢查之前取得，所述第二時間戳在所述完整性檢查和所述啟動檢查之后取得。
16.根據(jù)權利要求1所述的方法，其中所述確認消息包括設備配置的指示。
17.根據(jù)權利要求1所述的方法，其中所述確認消息包括設備組件的安全性屬性的指/Jn ο
18.根據(jù)權利要求1所述的方法，該方法還包括從所述PVE接收響應于所述確認消息的決定消息。
19.根據(jù)權利要求18所述的方法，其中所述決定消息包括與所述設備相關聯(lián)的網(wǎng)絡權限的指示。
20.一種用于經(jīng)由耦合到無線發(fā)射/接收單元(WTRU)的平臺確認實體(PVE)執(zhí)行所述WTRU的確認的設備，該設備包括: 處理器，位于所述WTRU中且用于執(zhí)行計算機可讀指令；以及 存儲器，位于所述WTRU中且通信耦合到所述處理器，所述存儲器已經(jīng)在其上存儲了當由所述處理器執(zhí)行時使得所述處理器執(zhí)行操作的計算機可讀指令，所述操作包括: 測量所述WTRU的至少 一個預先指定組件的完整性測量； 獲取所述WTRU的所述至少一個預先指定組件的可信參考值； 使用位于無線發(fā)射/接收單元(WTRU)中的可信環(huán)境(TrE)執(zhí)行所述WTRU的所述至少一個預先指定組件的完整性檢查，并將完整性檢查結(jié)果存儲在所述存儲器中；所述完整性檢查包括所述TrE比較所測量的所述至少一個預先指定組件的完整性測量與所述WTRU的所述至少一個預先指定組件的所述可信參考值； 使用所述TrE在所述WTRU上執(zhí)行安全啟動檢查，并將安全啟動檢查結(jié)果存儲在所述存儲器中；所述啟動檢查確定所述至少一個預先指定組件是否達到安全啟動的狀態(tài)，所述啟動檢查結(jié)果包括當所述至少一個預先指定組件沒有達到安全啟動的狀態(tài)時的指示； 使用所述TrE基于所述完整性檢查結(jié)果和所述安全啟動檢查結(jié)果形成確認消息；以及使用所述TrE和位于所述WTRU中的發(fā)射機將所述確認消息從所述WTRU轉(zhuǎn)發(fā)到所述PVE，所述PVE在所述WTRU外部。
【文檔編號】H04W12/10GK103716797SQ201410020579
【公開日】2014年4月9日 申請日期:2010年3月5日 優(yōu)先權日:2009年3月6日
【發(fā)明者】A·U·施米特, A·萊切爾, I·查, Y·C·沙阿, S·B·帕塔爾, D·F·豪利, D·G·格雷納, L·L·凱斯, M·V·邁爾施泰因, L·J·古喬內(nèi) 申請人:交互數(shù)字專利控股公司