用于將客戶端設(shè)備與網(wǎng)絡(luò)相連的系統(tǒng)和方法
【專利摘要】本發(fā)明提供了一種用于使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的系統(tǒng)和方法。所述方法包括：通過不同于網(wǎng)絡(luò)的通信信道獲得授權(quán)碼，所述授權(quán)碼與所述客戶端設(shè)備相對應(yīng)；以及在檢測到由所述客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操作。
【專利說明】用于將客戶端設(shè)備與網(wǎng)絡(luò)相連的系統(tǒng)和方法

【技術(shù)領(lǐng)域】
[0001] 下文涉及用于將客戶端設(shè)備與網(wǎng)絡(luò)相連的系統(tǒng)和方法。

【背景技術(shù)】
[0002] 在網(wǎng)絡(luò)環(huán)境中，希望加入網(wǎng)絡(luò)的客戶端設(shè)備首先發(fā)現(xiàn)網(wǎng)絡(luò)，然后加入所發(fā)現(xiàn)的網(wǎng) 絡(luò)。通常由路由器、服務(wù)器或其他網(wǎng)絡(luò)控制器或接入設(shè)備（下文中，稱作"信任中心"）來執(zhí) 行針對網(wǎng)絡(luò)的接受。在一些網(wǎng)絡(luò)環(huán)境中，加入網(wǎng)絡(luò)并且通過網(wǎng)絡(luò)進行通信的客戶端設(shè)備使 用少量用戶接口或不使用用戶接口來進行操作。盡管這種客戶端設(shè)備的接口有限，然而客 戶端設(shè)備應(yīng)當能夠不僅加入網(wǎng)絡(luò)，而且加入正確網(wǎng)絡(luò)。類似地，信任中心應(yīng)當能夠只允許可 接受的客戶端設(shè)備加入其網(wǎng)絡(luò)。
[0003] 諸如家域網(wǎng)（HAN)等的網(wǎng)絡(luò)可以將安全協(xié)商協(xié)議（例如傳輸層安全（TLS)協(xié)議或 其前身（安全套接層（SSL)協(xié)議））用作該網(wǎng)絡(luò)的基本安全協(xié)議。TLS協(xié)議是提供通信私密 性和數(shù)據(jù)完整性并且允許客戶端/服務(wù)器應(yīng)用以設(shè)計為防止或禁止竊聽、篡改和消息偽造 的方式進行通信的公知通信協(xié)議。
[0004] 在使用TLS或SSL協(xié)議的環(huán)境（包括向客戶端設(shè)備預(yù)配置數(shù)字證書（下文中，"證 書"）的環(huán)境）中，可能難以向正在加入的客戶端設(shè)備指示它應(yīng)當加入哪個網(wǎng)絡(luò)和信任中 心。還可能難以提取來自正在加入的客戶端設(shè)備的信息并且訪問信任中心以限定哪些客戶 端設(shè)備應(yīng)當加入。通常將這種困難稱作"操縱問題（steering problem)"。
[0005] 為了解決操縱問題，典型模型在于向信任中心提供與將加入網(wǎng)絡(luò)的客戶端設(shè)備有 關(guān)的少量標識信息。通常，標識信息應(yīng)具有允許人們通過終端或鍵盤容易輸入的形式。一 旦該信息在信任中心是已知的，信任中心就進入"允許加入"模式。此時，經(jīng)驗證的正在加 入的客戶端設(shè)備可以證明它是與標識信息相關(guān)聯(lián)的設(shè)備，并且被允許加入網(wǎng)絡(luò)。
[0006] 該模型的安全問題在于：欺詐信任中心可以在混雜模式下接受加入，從而欺騙正 在加入的客戶端設(shè)備加入錯誤網(wǎng)絡(luò)。另一安全問題在于：欺詐客戶端設(shè)備可以在允許加入 階段期間和在預(yù)期設(shè)備能夠加入之前嘗試通過信任中心加入網(wǎng)絡(luò)。


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

[0007] 在一個方面，提供了一種使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的方法，所述方法包括：通 過不同于網(wǎng)絡(luò)的通信信道獲得授權(quán)碼，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)；以及在檢測到由 客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操作。
[0008] 在另一方面，提供了一種與網(wǎng)絡(luò)相連的方法，所述方法包括：客戶端設(shè)備發(fā)起與網(wǎng) 絡(luò)的服務(wù)器設(shè)備的安全協(xié)商協(xié)議；以及將授權(quán)碼用于至少一個安全協(xié)商操作，所述授權(quán)碼 已經(jīng)通過不同于網(wǎng)絡(luò)的通信信道提供給服務(wù)器設(shè)備，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)。
[0009] 在另一方面，提供了一種使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的方法，所述方法包括：通 過不同于網(wǎng)絡(luò)的通信信道向客戶端設(shè)備提供授權(quán)碼，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)；以 及在檢測到由客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操 作。
[0010] 在另一方面，提供了一種計算機可讀存儲介質(zhì)，包括用于使客戶端設(shè)備能夠與網(wǎng) 絡(luò)相連的計算機可執(zhí)行指令，所述計算機可執(zhí)行指令包括用于以下操作的指令：通過不同 于網(wǎng)絡(luò)的通信信道獲得授權(quán)碼，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)；以及在檢測到由客戶端 設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操作。
[0011] 在另一方面，提供了一種計算機可讀存儲介質(zhì)，包括用于與網(wǎng)絡(luò)連接的計算機可 執(zhí)行指令，所述計算機可執(zhí)行指令包括用于以下操作的指令：客戶端設(shè)備發(fā)起與網(wǎng)絡(luò)的服 務(wù)器設(shè)備的安全協(xié)商協(xié)議；以及將授權(quán)碼用于至少一個安全協(xié)商操作，所述授權(quán)碼已經(jīng)通 過不同于網(wǎng)絡(luò)的通信信道提供給服務(wù)器設(shè)備，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)。
[0012] 在另一方面，提供了一種計算機可讀存儲介質(zhì)，包括用于使客戶端設(shè)備能夠與網(wǎng) 絡(luò)相連的計算機可執(zhí)行指令，所述計算機可執(zhí)行指令包括用于以下操作的指令：通過不同 于網(wǎng)絡(luò)的通信信道向客戶端設(shè)備提供授權(quán)碼，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)；以及在檢 測到由客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操作。
[0013] 在另一方面，提供了一種包括處理器和存儲器的服務(wù)器設(shè)備，所述存儲器包括計 算機可執(zhí)行指令，所述計算機可執(zhí)行指令用于通過操作所述處理器執(zhí)行以下操作來使客戶 端設(shè)備能夠與網(wǎng)絡(luò)相連：通過不同于網(wǎng)絡(luò)的通信信道獲得授權(quán)碼，所述授權(quán)碼與客戶端設(shè) 備相對應(yīng)；以及在檢測到由客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一 個安全協(xié)商操作。
[0014] 在另一方面，提供了一種包括處理器和存儲器的服務(wù)器設(shè)備，所述存儲器包括計 算機可執(zhí)行指令，所述計算機可執(zhí)行指令用于通過操作所述處理器執(zhí)行以下操作來使客戶 端設(shè)備與網(wǎng)絡(luò)相連：通過不同于網(wǎng)絡(luò)的通信信道向客戶端設(shè)備提供授權(quán)碼，所述授權(quán)碼與 客戶端設(shè)備相對應(yīng)；以及在檢測到由客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用 于至少一個安全協(xié)商操作。
[0015] 在另一方面，提供了一種包括處理器和存儲器的客戶端設(shè)備，所述存儲器包括計 算機可執(zhí)行指令，所述計算機可執(zhí)行指令用于通過操作所述處理器執(zhí)行以下操作來與網(wǎng)絡(luò) 連接：發(fā)起與網(wǎng)絡(luò)的服務(wù)器設(shè)備的安全協(xié)商協(xié)議；以及將授權(quán)碼用于至少一個安全協(xié)商操 作，所述授權(quán)碼已經(jīng)通過不同于網(wǎng)絡(luò)的通信信道提供給服務(wù)器設(shè)備，所述授權(quán)碼與客戶端 設(shè)備相對應(yīng)。

【專利附圖】

【附圖說明】
[0016] 現(xiàn)在將參考附圖僅通過舉例說明的方式描述實施例，在附圖中：
[0017] 圖1是包括網(wǎng)絡(luò)環(huán)境的通信系統(tǒng)的示意圖；
[0018] 圖2是包括家庭網(wǎng)絡(luò)的通信系統(tǒng)的示意圖；
[0019] 圖3是示出了網(wǎng)絡(luò)環(huán)境中的客戶端設(shè)備的配置的示例的框圖；
[0020] 圖4是示出了網(wǎng)絡(luò)環(huán)境中的信任中心的配置的示例的框圖；
[0021] 圖5是示出了網(wǎng)絡(luò)環(huán)境中使用的互聯(lián)網(wǎng)協(xié)議（IP)棧的框圖；
[0022] 圖6是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計算 機可執(zhí)行操作的集合以通過帶外信道向信任中心提供授權(quán)碼（AUTOCODE);
[0023] 圖7是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計算 機可執(zhí)行操作的集合以使用AUTOCODE來執(zhí)行TLS握手；
[0024] 圖8是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計算 機可執(zhí)行操作的集合以使用AUTOCODE來執(zhí)行TLS握手；
[0025] 圖9是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計算 機可執(zhí)行操作的集合以使用AUTOCODE來執(zhí)行TLS握手；
[0026] 圖10是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計 算機可執(zhí)行操作的集合以使用AUTOCODE來執(zhí)行TLS握手；
[0027] 圖11是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計 算機可執(zhí)行操作的集合以使用AUTOCODE來執(zhí)行針對TLS的密鑰材料導(dǎo)出（key material exporter)；
[0028] 圖12是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計 算機可執(zhí)行操作的集合以在TLS建立之后驗證AUTOCODE ;以及
[0029] 圖13是示出了計算機可執(zhí)行操作的集合的示例的流程圖，其中可以執(zhí)行所述計 算機可執(zhí)行操作的集合以使用AUTHC0DE來執(zhí)行經(jīng)修改的TLS建立。

【具體實施方式】
[0030] 應(yīng)認識到，為了使闡述簡單和清楚，在認為適當?shù)那闆r下可以在附圖中重復(fù)附圖 標記以指示相應(yīng)或相似的元素。此外，闡述了大量具體細節(jié)以便提供對這里所述示例的全 面理解。然而，本領(lǐng)域普通技術(shù)人員應(yīng)理解，可以在沒有這些具體細節(jié)的情況下實踐這里所 述的示例。在其他實例中，未詳細描述公知的方法、過程和組件以免混淆這里所述的示例。 此外，不應(yīng)認為該描述限制這里所述示例的范圍。
[0031] 應(yīng)認識到，這里所使用的示例和相應(yīng)附圖僅用于說明的目的。可以在不脫離這里 所述原理的情況下，使用不同的配置和術(shù)語。例如，可以添加、刪除、修改或用不同連接排列 組件和模塊，而不脫離這些原理。
[0032] 為了解決提供通信安全的網(wǎng)絡(luò)環(huán)境中的操縱問題，在信任中心和正在加入的客戶 端設(shè)備二者中建立針對特定客戶端設(shè)備的授權(quán)碼（AUTHC0DE)，并且將AUTHC0DE并入在相 應(yīng)的正在加入的客戶端設(shè)備與信任中心之間的安全協(xié)商中使用的至少一個操作。AUTHC0DE 使信任中心能夠識別正確的正在加入的設(shè)備并且使正在加入的設(shè)備能夠識別正確的信任 中心，從而確保它們加入了正確網(wǎng)絡(luò)。
[0033] 應(yīng)認識到，以下所述的原理可以用于多種安全協(xié)商協(xié)議，其中可以在帶外將 AUTHC0DE提供給信任中心，并且可以將這種AUTHC0DE用于由基本安全協(xié)商協(xié)議使用的 至少一個密碼操作。示例包括但不限于多種TLS協(xié)議版本，包括前身SSL版本和數(shù)據(jù)報 TLS(DTLS)、IPSec等。這里所提供的多種示例在使用TLS或SSL協(xié)議版本（下文中，為了 說明目的，稱作"TLS協(xié)議"）的網(wǎng)絡(luò)環(huán)境中說明了這些原理。
[0034] 在一個示例性場景中，客戶端設(shè)備可以與信任中心建立TLS會話，其中客戶端設(shè) 備和信任中心具有彼此識別的來自證書管理中心（CA)的經(jīng)驗證的簽名密鑰（例如，橢圓曲 線數(shù)字簽名算法（ECDSA)簽名密鑰）。在接受會話之前，向信任中心提供帶外的AUTHC0DE。 將要在加入階段期間使用的TLS協(xié)議修改為利用AUTOCODE。在這種場景下，假定合法的信 任中心和每個合法的客戶端設(shè)備以及任何欺詐客戶端設(shè)備具有或者另外能夠具有包含適 于ECDSA簽名的公鑰的有效證書并擁有相應(yīng)的私鑰。還假定所有正在加入的客戶端設(shè)備具 有相關(guān)聯(lián)的AUTOCODE。可以以多種方式將AUTOCODE提供在客戶端設(shè)備上或提供給客戶端 設(shè)備等，包括將其印刷在設(shè)備外部（例如，殼體背面）、相關(guān)包裝材料中等。AUTOCODE是打 算在帶外提供給信任中心而不通過加入的網(wǎng)絡(luò)來進行傳輸?shù)碾S機產(chǎn)生值。
[0035] 現(xiàn)在參考圖1，示出了包括局域網(wǎng)12的網(wǎng)絡(luò)環(huán)境10。通過信任中心14管理至少 一些設(shè)備對局域網(wǎng)12的接入。可以認識到，信任中心14可以表示任何路由器、服務(wù)器或其 他網(wǎng)絡(luò)控制器、或負責允許或拒絕客戶端設(shè)備接入局域網(wǎng)12的接入設(shè)備。在圖1所示的示 例中，示出了兩種客戶端設(shè)備，即，已注冊的客戶端設(shè)備16和正在加入的客戶端設(shè)備18。已 注冊的客戶端設(shè)備16包括已經(jīng)通過向信任中心14進行注冊成功加入局域網(wǎng)12的客戶端 設(shè)備。正在加入的客戶端設(shè)備18包括正試圖通過向信任中心14進行注冊加入局域網(wǎng)12 的客戶端設(shè)備?？梢哉J識到，正在加入的客戶端設(shè)備18可以包括合法客戶端設(shè)備和欺詐客 戶端設(shè)備二者。
[0036] 已注冊的客戶端設(shè)備16和正在加入的客戶端設(shè)備18都包括AUTHC0DE20,可以從 設(shè)備本身（例如，從設(shè)備的外部）確定所述AUTHC0DE20。為了將AUTHC0DE20用于至少一 個TLS操作，在正在加入的客戶端設(shè)備18與信任中心14之間建立帶外信道22。盡管將帶 外信道22示出為在網(wǎng)絡(luò)環(huán)境10內(nèi)，然而，還可以將帶外信道22建立在網(wǎng)絡(luò)環(huán)境10的外 部。帶外信道22可以包括例如由信任中心14提供的用戶接口，該用戶接口能夠?qū)崿F(xiàn)向信 任中心14、或由信任中心14控制的或另外信任中心14可訪問的數(shù)據(jù)庫或存儲器手動輸入 AUTHC0DE20。還可以使用與和信任中心14相關(guān)聯(lián)的管理員26的基于電話或web的連接建 立帶外信道22,從而當試圖向局域網(wǎng)12添加正在加入的客戶端設(shè)備18時使正在加入的客 戶端設(shè)備18的用戶能夠提供AUTHC0DE20。這樣，管理員26可以通過諸如如圖1所示的廣 域網(wǎng)24等的外部網(wǎng)絡(luò)，向信任中心14下推AUTHC0DE20。管理員26或信任中心14或管理 員26和信任中心14二者還可以通過廣域網(wǎng)24與證書管理中心（CA) 28進行通信，以獲得 例如在TLS協(xié)議中使用的證書。在使用證書的情況下，已注冊的客戶端設(shè)備16和正在加入 的客戶端設(shè)備18還包括經(jīng)驗證的簽名密鑰，因此還可以通過廣域網(wǎng)24與CA28進行通信。 可以認識到，在其他示例中，客戶端設(shè)備16、18可以不使用從CA28獲得的證書。例如，客戶 端設(shè)備16、18可以利用自簽名的證書或未簽名的公鑰，并且可以將AUTHC0DE20用于向信任 中心14認證這種客戶端設(shè)備16、18。
[0037] 圖2示出了網(wǎng)絡(luò)環(huán)境10的示例。圖2示出了例如針對智能家庭系統(tǒng)或高級計量 基礎(chǔ)設(shè)施（AMI)的包括家域網(wǎng)（HAN) 12'的家庭環(huán)境10'。通過被管理的服務(wù)門戶14'控 制該示例中的HAN12'，其中被管理的服務(wù)門戶14'允許已進行公共設(shè)施注冊的客戶端設(shè) 備（utility registered client device) 16'與HAN12'進行通信，并且允許或拒絕正在 進行公共設(shè)施加入的客戶端設(shè)備（utility joining client device) 18'的接入?？蛻舳?設(shè)備16'、18'可以包括例如電子溫控器、大型家用電器、HVAC系統(tǒng)等。與上述內(nèi)容相似，客 戶端設(shè)備16'、18'包括AUTHC0DE20并且通過帶外信道22'向被管理的服務(wù)門戶14'提供 AUTHC0DE20。被管理的服務(wù)門戶14'通過公共設(shè)施AMI網(wǎng)絡(luò)24'與公共設(shè)施后端服務(wù)器 26'進行通信。公共設(shè)施后端服務(wù)器26'負責與被管理的服務(wù)門戶14'進行通信，并且傳送 與正在進行公共設(shè)施加入的設(shè)備18'有關(guān)的信息并發(fā)起用于添加這種正在加入的設(shè)備18' 的加入周期。公共設(shè)施后端服務(wù)器26'還可以與CA28'進行通信，以獲得公共設(shè)施所使用 的被管理的服務(wù)門戶14'的經(jīng)驗證的簽名密鑰。被管理的服務(wù)門戶14'還可以安裝有已通 過采購實踐（procurement practice)存儲在其中的證書。然后，公共設(shè)施后端服務(wù)器26' 可以查找加入被管理的服務(wù)門戶14'的正在進行公共設(shè)施加入的設(shè)備18'的簽名/標識信 息，以確保還未撤銷證書。
[0038] 圖3示出了客戶端設(shè)備16、18的配置的示例。客戶端設(shè)備16、18包括主體、殼體 或提供外表面30的其他物理部分，可以將AUTHC0DE20印刷在外表面30上或以其他方式使 AUTHC0DE20對用戶是可見的?？蛻舳嗽O(shè)備16、18還包括局域網(wǎng)接口 32,以使處理器34能 夠例如使用TLS協(xié)議36與局域網(wǎng)12進行通信。如圖3所示的TLS協(xié)議36表示操作處理 器34以使客戶端設(shè)備16、18能夠參與TLS操作（例如，TLS握手、TLS應(yīng)用階段等）的任 何計算機可執(zhí)行指令?？蛻舳嗽O(shè)備16、18還包括用于存儲數(shù)據(jù)的存儲器38。在該示例中， 存儲器38存儲客戶端設(shè)備16、18的私鑰/公鑰對（c，C)和信任中心14的公鑰T。存儲器 38還存儲AUTHC0DE40的電子版本或表示，以使印刷在客戶端設(shè)備16、18的外表面30上的 AUTHC0DE20能夠用于TLS操作。
[0039] 圖4示出了信任中心14的配置的示例。該示例中的信任中心14包括：處理器50 ; 局域網(wǎng)接口 52,用于通過局域網(wǎng)12進行通信；以及廣域網(wǎng)接口 54,用于通過廣域網(wǎng)24進行 通信?？梢哉J識到，僅為了說明目的，將局域網(wǎng)接口 52和廣域網(wǎng)接口 54示出為單獨組件， 并且可以使用單個網(wǎng)絡(luò)接口模塊。處理器50有權(quán)訪問TLS協(xié)議56并且有權(quán)訪問存儲器 58。存儲器58存儲信任中心14的私鑰/公鑰對（t，T)。存儲器58還存儲客戶端設(shè)備16、 18的公鑰C，通常在執(zhí)行安全協(xié)商協(xié)議期間例如使用證書將公鑰C提供給信任中心14。信 任中心14還包括或者另外有權(quán)訪問客戶端設(shè)備AUTOCODE數(shù)據(jù)庫60,客戶端設(shè)備AUTOCODE 數(shù)據(jù)庫60用于存儲已注冊的客戶端設(shè)備16和那些利用帶外信道22正在加入的客戶端設(shè) 備18的AUTHC0DE40的電子版本或表示。
[0040] 現(xiàn)在參考圖5,在500,可以通過使用帶外信道22從客戶端設(shè)備16、18向信任中 心14提供AUTHC0DE20,來使用AUTHC0DE40修改TLS協(xié)議。例如，當用戶希望向局域網(wǎng)12 添加新的正在加入的客戶端設(shè)備18時，可以訪問由信任中心14提供的用戶接口，并且將 AUTHC0DE40的表示輸入該用戶接口。然后，在502,正在加入的客戶端設(shè)備18可以發(fā)起與 信任中心14的TLS會話。然后，在504,將由正在加入的客戶端設(shè)備18存儲的AUTHC0DE40 用于一個或多個TLS操作，下文提供了其示例。假定信任中心14已經(jīng)成功地獲得并使用了 存儲在AUTOCODE數(shù)據(jù)庫60中的相同AUTHC0DE40,則在506,允許正在加入的客戶端設(shè)備18 使用已建立的安全信道接入局域網(wǎng)12,此后信任中心14將正在加入的客戶端設(shè)備18視作 已加入的客戶端設(shè)備16,從而提供對例如網(wǎng)絡(luò)資源等的訪問。類似地，已加入的客戶端設(shè)備 16現(xiàn)在確保已加入的客戶端設(shè)備16已經(jīng)加入了正確的信任中心14。
[0041] 圖6示出了操作集合的示例，該操作集合可以執(zhí)行以使信任中心14和正在加入的 客戶端設(shè)備18能夠參與TLS握手。CA28在600產(chǎn)生針對信任中心14的證書并且在602 向信任中心14提供該證書，并且在604,信任中心獲得該證書。可以認識到，操作600-604 是可選的，這取決于是否使用證書，并且可以使用任意適合的證書實現(xiàn)過程（可以包括證 書撤銷檢查或證書驗證）來提供向信任中心14頒發(fā)的證書。在606,將正在加入的客戶端 設(shè)備18引入網(wǎng)絡(luò)環(huán)境10,并且在608,確定在正在加入的客戶端設(shè)備18的外表面30上提 供的AUTHC0DE20。在610,建立帶外信道22,在612,由信任中心14啟用帶外信道22。例 如，信任中心14可以提供基于瀏覽器的用戶接口，以使得能夠輸入AUTHC0DE20。在614， 提供AUTHC0DE20,并且在616,由信任中心14接收AUTHC0DE20。在618,信任中心14將 AUTHC0DE40的表示存儲在AUTOCODE數(shù)據(jù)庫60中。然后，在620,信任中心14發(fā)起針對與 所存儲的AUTHC0DE20相關(guān)聯(lián)的正在加入的客戶端設(shè)備18的允許加入階段。一旦已經(jīng)發(fā)起 允許加入階段，正在加入的客戶端設(shè)備18就可以在622發(fā)起TLS會話，并參與TLS握手以 便注冊正在加入的客戶端設(shè)備18。在624,信任中心14也參與TLS握手。
[0042] 圖7示出了計算機可執(zhí)行操作的集合，該計算機可執(zhí)行操作集合可以由正在加 入的客戶端設(shè)備18或信任中心14執(zhí)行以使用通過帶外信道22提供給信任中心14的 AUTHC0DE40。在700,從存儲器38、60獲得與已經(jīng)發(fā)起TLS會話的正在加入的客戶端設(shè)備 18相關(guān)聯(lián)的已存儲的AUTHC0DE40。在702,將AUTHC0DE40用于一個或多個TLS操作，并且 在704完成TLS握手。
[0043] 可以認識到，存在用于執(zhí)行TLS握手的多種基于TLS的機制。因此，當施加到使用 TLS或SSL的應(yīng)用時，存在多種方式來將AUTHC0DE40用于解決上述操縱問題。下文提供了多 個示例，在這些示例中，將AUTHC0DE40用于一個或多個TLS操作，以促使正確的正在加入的 客戶端設(shè)備18與正確的信任中心14進行通信并且向正確的信任中心14注冊，從而加入正 確的局域網(wǎng)12。在以下示例中，可以假定所使用的TLS協(xié)議包括密鑰交換算法，例如，在TLS RFC4492文檔的橢圓曲線加密法（ECC)密碼套件（cipher suite)中描述的算法。以下示例 可以使用臨時橢圓曲線迪菲-赫爾曼（Diffie Heilman)和E⑶SA(E⑶HE_EOTSA)密鑰交換算 法。然而，可以認識到，這里所述的原理還可以應(yīng)用于其他密鑰交換算法，例如ECDH_ECDSA、 EOTH_RSA、E⑶HE_RSA等，其中客戶端設(shè)備16、18和信任中心14可以根據(jù)AUTHC0DE40推衍 (derive)最終的會話密鑰。
[0044] 現(xiàn)在參考圖8,示出了正在加入的客戶端設(shè)備18用AUTHC0DE40代替在TLS握手 期間使用的ClientHello消息中包括的隨機值的示例。如本領(lǐng)域公知的，TLS握手中的 ClientHello消息是在協(xié)商階段期間發(fā)送的并且由客戶端發(fā)送以指定客戶端支持的最高的 TLS協(xié)議版本并且提供隨機數(shù)、建議密碼套件的列表和壓縮方法。對于如圖8所示的示例， 可以假定當在TLS中執(zhí)行ECDHE_ECDSA時，ClientHello. random值對TLS會話的整體安全 性沒有貢獻。應(yīng)認識到，可以將ClientHello. random值重新目的化為AUTHC0DE40的知識 (knowledge)的證據(jù)，并且還應(yīng)認識到在TLS握手期間，在產(chǎn)生master_secret (主密鑰）和 key_block(密鑰塊）的操作中可以用 AUTHC0DE40 代替 ClientHello. random 值。
[0045] 假定正在加入的客戶端設(shè)備18和信任中心14都具有AUTHC0DE40 (即，在正在加 入的客戶端設(shè)備18發(fā)起TLS會話之后，已經(jīng)通過帶外信道22將AUTHC0DE20發(fā)送或以其 他方式提供給信任中心14)，在800,正在加入的客戶端設(shè)備18使用HASH函數(shù)（例如，由 TLS會話使用的密碼散列）變換AUTHC0DE40。然后，正在加入的客戶端設(shè)備18在802將 AUTHC0DE40的散列用作ClientHello. random值來產(chǎn)生ClientHello消息，并且在804將 ClientHello消息發(fā)送給信任中心14。信任中心14在806接收ClientHello消息，并且在 808將該消息中的ClientHello. random值與由信任中心14產(chǎn)生的AUTHC0DE40的散列進行 比較。
[0046] 信任中心14在810確定是否匹配。如果比較的值不同，則在812, TLS會話由于 錯誤而停止，并且終止該處理。如果比較的值匹配，貝1J在814,信任中心14在計算master_ secret和key_block期間，在內(nèi)部使用AUTHC0DE40來執(zhí)行TLS握手的其余部分。在 816,正在加入的客戶端設(shè)備18也在計算master_secret和key_block期間，在內(nèi)部使用 AUTHC0DE40而不是Cl ientHe 11 〇. random值來執(zhí)行其余TLS握手操作。因此，僅當信任中心 14得知AUTHC0DE40并如上所述的將該AUTHC0DE40用于執(zhí)行master_secret和key_block 計算時，在818和820處，TLS握手才將成功地完成并進入應(yīng)用階段。
[0047] 現(xiàn)在參考圖9,示出了信任中心14用AUTHC0DE40代替在TLS握手期間使用的 ServerHello消息中包括的隨機值的示例。如本領(lǐng)域公知的，TLS握手中的ServerHello消 息是在協(xié)商階段期間作為對ClientHello消息的響應(yīng)發(fā)送的，并且由服務(wù)器發(fā)送以指定所 選的TLS協(xié)議版本并且根據(jù)由客戶端提供的選擇來提供隨機數(shù)、密碼套件和壓縮方法。對 于圖9所示的示例，可以假定當在TLS中執(zhí)行E⑶HE_EOTSA時，ServerHello. random值對 TLS會話的整體安全性沒有貢獻。應(yīng)認識到，可以將ServerHello. random值重新目的化 為AUTHC0DE40的知識的證據(jù)，并且還應(yīng)認識到在TLS握手期間，在產(chǎn)生master_secret和 key_block 的操作中可以用 AUTHC0DE40 代替 ServerHello. random 值。
[0048] 假定正在加入的客戶端設(shè)備18和信任中心14都具有AUTHC0DE40( S卩，在正在 加入的客戶端設(shè)備18發(fā)起TLS會話之后，已經(jīng)通過帶外信道22將AUTHC0DE20發(fā)送或 以其他方式提供給信任中心14)，在900,正在加入的客戶端設(shè)備18向信任中心14發(fā)送 ClientHello消息，在902,信任中心14接收該消息。在904,信任中心14使用HASH函數(shù)（例 如，由TLS會話使用的密碼散列）變換AUTHC0DE40。然后，信任中心14在906將AUTHC0DE40 的散列用作ServerHello. random值來產(chǎn)生ServerHello消息，并且在908將ServerHello 消息發(fā)送給正在加入的客戶端設(shè)備18。正在加入的客戶端設(shè)備18在910接收ServerHello 消息，并且在912將該消息中的ServerHello. random值與由正在加入的客戶端設(shè)備18產(chǎn) 生的AUTHC0DE40的散列進行比較。
[0049] 正在加入的客戶端設(shè)備18在914確定是否匹配。如果比較的值不同，則在916， TLS會話由于錯誤而停止，并且終止該處理。如果比較的值匹配，則在918,正在加入的客戶 端設(shè)備18在計算master_secret和key_block期間，在內(nèi)部使用AUTHC0DE40來執(zhí)行TLS 握手的其余部分。在920,信任中心14也在計算master_secret和key_block期間，在內(nèi)部 將AUTHC0DE40用作ServerHello. random值來執(zhí)行其余TLS握手操作。因此，僅當正在加 入的客戶端設(shè)備18得知AUTHC0DE40并如上所述的將AUTHC0DE40代入master_secret和 key_bl〇ck計算時，在922和924處，TLS握手才將成功地完成并進入應(yīng)用階段。
[0050] 現(xiàn)在參考圖10,還應(yīng)認識到可以將AUTHC0DE40用于產(chǎn)生針對E⑶HE計算的第二 基點，而不影響TLS會話的整體安全性。因此可以將第二基點用于在TLS握手中形成pre_ master_secret。在圖10所示的示例中，可以通過附加的標量乘法修改協(xié)商的ECDHE值Q， 艮P :AUTHC0DE*Q，其中將AUTHC0DE解釋為以TLS會話正在其中操作的橢圓曲線群的基點的 階數(shù)為模的整數(shù)。
[0051] 在1000和1002,正在加入的客戶端設(shè)備18和信任中心14根據(jù)所使用的TLS算 法來分別執(zhí)行一個或多個初始TLS握手操作。例如，正在加入的客戶端設(shè)備18和信任中 心14可以交換ClientHello和ServerHello消息、證書和證書請求消息等。在1004,正在 加入的客戶端設(shè)備18通過計算Q' = AUTHC0DE*Q，來修改密鑰橢圓曲線點Q。如上所述，將 AUTHC0DE40解釋為以TLS會話正在其中操作的橢圓曲線群的階數(shù)為模的整數(shù)。然后，正在 加入的客戶端設(shè)備18在1006使用Q'的x坐標形成pre_master_secret，并且在1008執(zhí)行 任意其余TLS握手操作，其中僅當信任中心14同樣得知AUTHC0DE40并以類似方式修改共 享的密鑰橢圓曲線點Q時，TLS握手才將成功地完成。
[0052] 因此，在1010,信任中心14通過計算Q' = AUTHC0DE*Q，來修改密鑰橢圓曲線點 Q。如上所述，將AUTHC0DE40解釋為以TLS會話正在其中操作的橢圓曲線群的階數(shù)為模的 整數(shù)。然后，信任中心14在1012使用Q'的X坐標形成pre_master_secret，并且在1014 執(zhí)行任意其余TLS握手操作，其中僅當正在加入的客戶端設(shè)備18同樣得知AUTHC0DE40并 以類似方式修改共享的密鑰橢圓曲線點Q時，TLS握手才將成功地完成。
[0053] 假定TLS握手是成功的，在1016和1018,正在加入的客戶端設(shè)備18和信任中心 14分別進入TLS應(yīng)用階段。
[0054] 如在例如RFC5705中定義的，可以從協(xié)商的TLS會話中提取附加的密碼密鑰。參考 圖11，應(yīng)認識到，可以通過在協(xié)商TLS會話之后交換PRF ()函數(shù)的輸出使客戶端和服務(wù)器證 明AUTHC0DE40的知識，來修改TLS方法的密鑰材料導(dǎo)出（keying material exporter)以 提供針對操縱問題的解決方案。在1100和1102,正在加入的客戶端設(shè)備18和信任中心14 分別通過（例如使用E⑶HE_EOTSA密鑰交換算法）執(zhí)行TLS握手來參與建立TLS會話。在 1104,正在加入的客戶端設(shè)備18通過將AUTHC0DE40添加到PRF0函數(shù)中作為"標簽"值的 一部分或"上下文"值的一部分，來產(chǎn)生RFC5705中定義的導(dǎo)出操作。如本領(lǐng)域公知的，如果 沒有提供上下文，則 PRF()函數(shù)計算：PRF(master_secret，label，client_random+server_ random) [length],其中PRF()是在會話中使用的TLS偽隨機函數(shù)。如果提供了上下文，貝丨J PRF()函數(shù)計算：PRF(master_secret, label, client_random+server_random+context_ value_length+context_value) [length]。PRF ()的輸出是根據(jù) master_secret 產(chǎn)生的 [length]個字節(jié)的偽隨機比特串。
[0055] 在1106,正在加入的客戶端設(shè)備18將輸出解析為兩個不同數(shù)據(jù)要素：SERVER_ PROOF]ICLIENT_PR00F = PRF(master_secret, label, client_random+server_ random+context_value_length+context_value)[length],并在 1108 發(fā)送 CLIENT_ PROOF。同時，信任中心14在1110也通過將AUTHC0DE40添加到PRF()函數(shù)中作為"標 簽"值或"上下文"值來產(chǎn)生RFC5705中定義的導(dǎo)出操作，并在1112將輸出標記為 ： SERVER_PR00F||CLIENT_PR00F = PRF(master_secret, label, client_random+server_ random+context_value_length+context_value)[length]〇
[0056] 信任中心14在1114接收CLIENT_PR00F，并且在接收到CLIENT_PR00F之后，在 1116將接收到的CLIENT_PR00F與使用上述關(guān)系計算出的CLIENT_PR00F值進行比較。信 任中心14在1118確定這些值是否匹配。如果比較的值不同，則TLS會話在1120由于錯誤 而停止，并且認為正在加入的客戶端設(shè)備18是不正確的。如果比較的值相匹配，則信任中 心14在1122確定正確的客戶端已經(jīng)加入，并且在1124向正在加入的客戶端設(shè)備18發(fā)送 SERVER_PR00F。
[0057] 正在加入的客戶端設(shè)備18在1126接收SERVER_PR00F，并且在接收到SERVER_ PROOF之后，在1128將接收到的SERVER_PR00F與上述計算出的SERVER_PR00F值進行比較。 正在加入的客戶端設(shè)備18在1130確定這些值是否匹配。如果比較的值不同，則TLS會話 在1132由于錯誤而停止，并且認為正在加入的客戶端設(shè)備18加入了錯誤的網(wǎng)絡(luò)。如果比 較的值相匹配，則正在加入的客戶端設(shè)備18在1134確定它已加入正確的局域網(wǎng)12。
[0058] 可以認識到，上述原理可以應(yīng)用于其他安全協(xié)商協(xié)議（包括多種基于TLS和SSL 的密鑰協(xié)定方案），例如，TLS_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_256_CBC_SHA 等。此外，如RFC2246的6. 3節(jié)所述，可以通過例如在推衍key_block之前將AUTHC0DE40 附加到 master_secret 或者將 AUTHC0DE40 與 master_secret 進行異或，使 AUTHC0DE40 參 與 master_secret 或 key_block 計算。
[0059] 還可以認識到，由于印刷、讀取和輸入代碼所需的任務(wù)的性質(zhì)，使AUTHC0DE40包 括足夠的熵或隨機性（這可能導(dǎo)致有效AUTHC0DE40的空間成為可耗盡的集合）是不切實 際的。在這種情況下，攻擊者可以通過填充與HASH (AUTOCODE)相對應(yīng)的值的數(shù)據(jù)庫，來執(zhí) 行字典式攻擊，并且等待ClientHello消息并針對檢測到的散列值查找正確的AUTOCODE。 可以通過散布（salt)散列輸出來部分地阻礙這種攻擊。例如，可以將ClientHello. random 值可以分為兩個部分：ClientHello. random = SALT | | HASH (SALT | lAUTHCODE)， 其中SALT是隨機產(chǎn)生的足夠大的值，例如，大至足以針對（SALT，AUTOCODE)的所有值防 止創(chuàng)建值"SALT | | HASH (SALT | | AUTHC0DE)"的字典。例如，對于多個應(yīng)用，將SALT設(shè)置 為80比特隨機值可能是足夠的。盡管這種散布技術(shù)可以使得免受字典式攻擊，然而這種 情況下的較低熵AUTHC0DE40仍然可能容易受到蠻力攻擊，在蠻力攻擊中，攻擊者觀察合 法加入以及值 ClientHello. random = SALT | |HASH(SALT| IAUTHC0DE)，并且離線以計算 HASH(SALT| |AUTHC0DE)直到發(fā)現(xiàn)正確的AUTHC0DE40為止。應(yīng)認識到，當AUTHC0DE40沒有 足夠的隨機性時，圖8到圖11所示的方法可能容易受到字典式攻擊和蠻力攻擊之一或二 者。
[0060] 為了解決這些可能的攻擊，現(xiàn)在將描述對TLS協(xié)議的附加修改和附加的TLS會 話建立后的驗證，所述對TLS協(xié)議的附加修改和附加的TLS會話建立后的驗證可以基于 IEEE1363. 2中所述的基于口令的密鑰協(xié)定方案和安全遠程口令的使用。
[0061] 現(xiàn)在參考圖12,示出了在加入過程期間通過已建立的TLS會話驗證AUTHC0DE40的 方法。在1200和1202,圖12所述的方法分別在正在加入的客戶端設(shè)備18與信任中心14 之間建立TLS連接，然后用密鑰確認（例如，在IEEE1363. 2中規(guī)定的EC-SPEKE)執(zhí)行基于 口令的密鑰協(xié)定協(xié)議。
[0062] 在1204,正在加入的客戶端設(shè)備18通過計算：Q = f(HASH(ClientID| | " · " | | (C lientHello. random | |ServerHello. random | |AUTHC0DE)))在捕圓曲線上產(chǎn)生基點 Q，其中 f是得到HASH的輸出并將該輸出映射到期望曲線上的橢圓曲線點的適合函數(shù)。然后，正在 加入的客戶端設(shè)備18在1206產(chǎn)生隨機值a并計算Q A = aQ。然后在1208將QA發(fā)送給信 任中心14。信任中心14在1210也以與正在加入的客戶端設(shè)備18相同的方式產(chǎn)生Q，并且 在1212產(chǎn)生隨機值b并計算Q B = bQ。信任中心14在1214接收到QA并在1216計算K = KDF(bQA)。可以認識到，KDF是適合的密鑰推衍函數(shù)，例如，IEEE1363. 2中所述的KDF。然 后，信任中心14產(chǎn)生塊SERVER_PR00F
[0063] CLIENT_PR00F = PRF(K,(其他信息，例如 ClientHello. random、ServerHello. random等））。例如，所述塊可以包括以下格式：SERVER_PR00F| |CLIENT_PR00F =PRF (master_Secret, label, client_random+server_random+context_value_ length+context_value) [length]，如上文所使用的。信任中心14在1236向正在加入的客 戶端設(shè)備18發(fā)送QB和SERVER_PROOF。
[0064] 正在加入的客戶端設(shè)備18在1222接收到％和SERVER_PR00F，并在1224產(chǎn)生K = KDF (aQB)。然后，正在加入的客戶端設(shè)備18在1226產(chǎn)生塊SERVER_PR00F | | CLIENT_PR00F =PRF (K，（其他信息，例如 ClientHello. random、ServerHello. random 等））。例如，所述塊 可以包括以下格式：SERVER_PR00F| |CLIENT_PR00F = PRF(master_secret，label，client_ random+server_random+context_value_length+context_value) [length],如上文所使用 的。正在加入的客戶端設(shè)備18在1228將接收到的SERVER_PR00F與根據(jù)所述塊計算出的 SERVER_PR00F進行比較。正在加入的客戶端設(shè)備18在1230確定這些值是否匹配。如果不 匹配，則在1232停止會話并指示錯誤。如果SERVER_PR00F值匹配，則正在加入的客戶端設(shè) 備18在1234向信任中心14發(fā)送CLIENT_PR00F，信任中心14在1238接收到CLIENT_PR00F。 信任中心14在1240將接收到的CLIENT PROOF與根據(jù)所述塊計算出的CLIENT_PR00F進行 比較，并且在1242確定這些值是否匹配。如果不匹配，則在1244斷開連接從而指示錯誤。 如果CLIENT_PR00F值匹配，則在1246允許正在加入的客戶端設(shè)備18加入局域網(wǎng)12。
[0065] 現(xiàn)在參考13,示出了在加入處理中在建立TLS會話期間驗證AUTHC0DE的方法。應(yīng) 認識到，在TLS會話的ECDH方案中使用的基點可以被修改以驗證AUTHC0DE，并且可以使用 基于口令的密鑰協(xié)定協(xié)議以便直接建立TLS會話密鑰。僅當由兩個端點使用的AUTHC0DE40 是相同的，TLS會話才是成功的。
[0066] 如圖13所示，當在1300和1302分別參與建立TLS會話之后，正在加入的客戶端設(shè) 備18和信任中心14可以在1304和1308分別產(chǎn)生新的基點Q。將新的基點用于E⑶Η操作， 其中 Q = f(HASH(AGREED_UPON_STRING| | " (ClientHello. random) | | (ServerHello. random I I AUTOCODE)))，其中f是得到HASH的輸出并在TLS協(xié)商曲線上產(chǎn)生橢圓曲線點的 適合函數(shù)。
[0067] 客戶端在1306將基點Q用作基點進行E⑶HE密鑰交換，并且信任中心14在1310 類似地使用Q。
[0068] 可以認識到，考慮到兩種解決方案之間的相似性，上述原理還可以用于數(shù)據(jù)報 TLS (DTLS)。DTLS協(xié)議確保UDP網(wǎng)絡(luò)通信安全性，并且被設(shè)計為與TLS相似，以便使大多數(shù) 協(xié)議消息保持相同，從而允許許多相同的TLS密碼套件用于DTLS。一些機器到機器的網(wǎng)絡(luò) (例如，如圖1和2所示的網(wǎng)絡(luò)）可以使用UDP和DTLS。針對這種環(huán)境設(shè)計的一個示例性 應(yīng)用層協(xié)議是CoAP，其目的在于通過UDP提供類似HTTP的協(xié)議，并且用DTLS確保安全性。 當用"證書模式"確保CoAP的安全性時，S卩，用證書提供安全性，可能存在上述的操縱問題。 因此，可以應(yīng)用這里所述的原理以解決這種操縱問題。
[0069] 類似地，如上所述，AUTHC0DE40還可以用于諸如IPSec等的其他安全協(xié)商協(xié)議中。 例如，可以通過將互聯(lián)網(wǎng)密鑰交換（IKE)修改為在密鑰推衍步驟中包括AUTOCODE (RFC4306 的2. 13節(jié)中針對IKE v2所述的），來修改IPSec中使用的密鑰協(xié)定協(xié)議。
[0070] 因此，提供了一種使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的方法，所述方法包括：通過不同 于網(wǎng)絡(luò)的通信信道獲得授權(quán)碼，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)；以及在檢測到由客戶端 設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操作。
[0071] 還提供了一種與網(wǎng)絡(luò)相連的方法，所述方法包括：客戶端設(shè)備發(fā)起與網(wǎng)絡(luò)的服務(wù) 器設(shè)備的安全協(xié)商協(xié)議；以及將授權(quán)碼用于至少一個安全協(xié)商操作，所述授權(quán)碼已經(jīng)通過 不同于網(wǎng)絡(luò)的通信信道提供給服務(wù)器設(shè)備，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)。
[0072] 提供了一種使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的方法，所述方法包括：通過不同于網(wǎng) 絡(luò)的通信信道向客戶端設(shè)備提供授權(quán)碼，所述授權(quán)碼與客戶端設(shè)備相對應(yīng)；以及在檢測到 由客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全協(xié)商操作。
[0073] 還提供了一種包括用于執(zhí)行上述方法的指令的計算機可讀介質(zhì)、以及被配置用于 執(zhí)行上述方法的客戶端設(shè)備和服務(wù)器設(shè)備。
[0074] 應(yīng)認識到，這里所例示的執(zhí)行指令的任何模塊或組件可以包括或另外有權(quán)訪問計 算機可讀介質(zhì)，例如，存儲介質(zhì)、計算機存儲介質(zhì)、或諸如磁盤、光盤或磁帶等的數(shù)據(jù)存儲設(shè) 備（可移除的和/或不可移除的）。計算機存儲介質(zhì)可以包括易失性的和非易失性的、可移 除的和不可移除的介質(zhì)，所述介質(zhì)實現(xiàn)在任何方法或技術(shù)中以用于存儲信息，例如計算機 可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其他數(shù)據(jù)。計算機存儲介質(zhì)的示例包括：ram、rom、eeprom、 閃存或其他存儲技術(shù)、CD-ROM、數(shù)字通用光盤（DVD)或其他光學存儲設(shè)備、磁帶盒、磁帶、磁 盤存儲器或其他磁性存儲設(shè)備、或可以用于存儲所需信息并可以由應(yīng)用、模塊或二者訪問 的任何其他介質(zhì)。任何這種計算機存儲介質(zhì)可以是**的一部分、**的任何組件或與**相 關(guān)的任何組件等，或可訪問或可連接?？梢允褂糜嬎銠C可讀/可執(zhí)行指令來實現(xiàn)這里所述 的任何應(yīng)用或模塊，其中通過這種計算機可讀介質(zhì)存儲或另外保存所述計算機可讀/可執(zhí) 行指令。
[0075] 這里所述的流程圖和示意圖中的步驟或操作僅是示例性的。可以存在對這種步驟 或操作的多種變型，而不脫離上述的原理。例如，可以以不同順序執(zhí)行所述步驟，或可以添 力口、刪除或修改所述步驟。
[0076] 盡管參考一些具體示例描述了以上原理，然而如所附權(quán)利要求所述，多種修改對 于本領(lǐng)域技術(shù)人員而言將是顯而易見的。
【權(quán)利要求】
1. 一種使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的方法，所述方法包括： 通過不同于所述網(wǎng)絡(luò)的通信信道獲得授權(quán)碼，所述授權(quán)碼與所述客戶端設(shè)備相對應(yīng)； 以及 在檢測到由所述客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全 協(xié)商操作。
2. 根據(jù)權(quán)利要求1所述的方法，還包括至少一個以下操作： 當安全協(xié)商成功時，允許所述客戶端設(shè)備訪問至少一個網(wǎng)絡(luò)資源；以及 獲得所述客戶端設(shè)備的公鑰，并將所述公鑰和所述授權(quán)碼用于向服務(wù)器設(shè)備認證所述 客戶端設(shè)備。
3. 根據(jù)權(quán)利要求2所述的方法，所述客戶端設(shè)備的所述公鑰是在數(shù)字證書中提供的。
4. 根據(jù)權(quán)利要求1到3中任一項所述的方法，將所述授權(quán)碼用于建立傳輸層安全TLS 會話。
5. 根據(jù)權(quán)利要求4所述的方法，還包括至少一個以下操作： 將所述授權(quán)碼用于產(chǎn)生master_secret、key_block和pre_master_secret中的至少 一個，其中所述master_secret、所述key_block和所述pre_master_secret是在建立所述 TLS會話期間產(chǎn)生的； 將所述授權(quán)碼用于PRFO函數(shù)； 將所述授權(quán)碼用于在建立所述TLS會話期間的密鑰交換；以及 將所述授權(quán)碼用于在建立所述TLS會話期間的密鑰推衍步驟。
6. 根據(jù)權(quán)利要求1到5中任一項所述的方法，在使用所述安全協(xié)商協(xié)議完成安全會話 之后，將所述授權(quán)碼用于建立密鑰。
7. -種與網(wǎng)絡(luò)相連的方法，所述方法包括： 客戶端設(shè)備發(fā)起與所述網(wǎng)絡(luò)的服務(wù)器設(shè)備的安全協(xié)商協(xié)議；以及 將授權(quán)碼用于至少一個安全協(xié)商操作，所述授權(quán)碼已經(jīng)通過不同于所述網(wǎng)絡(luò)的通信信 道提供給所述服務(wù)器設(shè)備，所述授權(quán)碼與所述客戶端設(shè)備相對應(yīng)。
8. 根據(jù)權(quán)利要求7所述的方法，還包括至少一個以下操作： 在安全協(xié)商成功之后，訪問至少一個網(wǎng)絡(luò)資源；以及 獲得所述服務(wù)器設(shè)備的公鑰，并將所述公鑰和所述授權(quán)碼用于向所述服務(wù)器設(shè)備認證 所述客戶端設(shè)備。
9. 根據(jù)權(quán)利要求8所述的方法，所述服務(wù)器設(shè)備的所述公鑰是在數(shù)字證書中提供的。
10. 根據(jù)權(quán)利要求7到9中任一項所述的方法，將所述授權(quán)碼用于建立傳輸層安全TLS 會話。
11. 根據(jù)權(quán)利要求10所述的方法，還包括至少一個以下操作： 將所述授權(quán)碼用于產(chǎn)生master_secret、key_block和pre_master_secret中的至少 一個，其中所述master_secret、所述key_block和所述pre_master_secret是在建立所述 TLS會話期間產(chǎn)生的； 將所述授權(quán)碼用于PRF0函數(shù)； 將所述授權(quán)碼用于在建立所述TLS會話期間的密鑰交換；以及 將所述授權(quán)碼用于在建立所述TLS會話期間的密鑰推衍步驟。
12. 根據(jù)權(quán)利要求7到11中的任一項所述的方法，在使用所述安全協(xié)商協(xié)議完成安全 會話之后，將所述授權(quán)碼用于建立密鑰。
13. -種使客戶端設(shè)備能夠與網(wǎng)絡(luò)相連的方法，所述方法包括： 通過不同于所述網(wǎng)絡(luò)的通信信道向所述客戶端設(shè)備提供授權(quán)碼，所述授權(quán)碼與所述客 戶端設(shè)備相對應(yīng)；以及 在檢測到由所述客戶端設(shè)備發(fā)起安全協(xié)商協(xié)議之后，將所述授權(quán)碼用于至少一個安全 協(xié)商操作。
14. 一種計算機可讀存儲介質(zhì)，包括用于執(zhí)行根據(jù)權(quán)利要求1到13中任一項所述方法 的計算機可執(zhí)行指令。
15. -種設(shè)備，包括處理器和存儲器，所述存儲器包括計算機可執(zhí)行指令，所述計算機 可執(zhí)行指令用于作為服務(wù)器設(shè)備根據(jù)權(quán)利要求1到6或權(quán)利要求13中任一項所述的方法 操作或者用于作為客戶端設(shè)備根據(jù)權(quán)利要求7到12中任一項所述的方法操作。
【文檔編號】H04L9/32GK104160656SQ201380012082
【公開日】2014年11月19日 申請日期:2013年2月28日 優(yōu)先權(quán)日:2012年3月1日
【發(fā)明者】馬修·約翰·坎帕尼亞, 丹尼爾·理查德·L·布朗, 格雷戈里·馬克·扎韋魯哈 申請人:塞爾蒂卡姆公司