戶(hù)端和服務(wù)器雙向認(rèn)證，則它們之間的安全通道就得W構(gòu) 成，222。在認(rèn)證過(guò)程中使用的新鮮值W及密鑰在不同的會(huì)話(huà)中會(huì)改變?？墒褂糜?jì)時(shí)器刷新 會(huì)話(huà)。本發(fā)明設(shè)及的系統(tǒng)包括附加在計(jì)時(shí)器（計(jì)數(shù)器）上的偽隨機(jī)數(shù)生成器（PRNG)，在每 次會(huì)話(huà)期間提供唯一的密鑰^及唯一的128位的新鮮值。因此，由于32| (PRN)的隨機(jī)性^ 及(定時(shí)器）單調(diào)增加的特性，因此新鮮值為非重復(fù)性的。偽隨機(jī)的方式生成，并 且其對(duì)的包含確保避免了重發(fā)攻擊：
[0064] (Pr化|t=T=Rj|t=T'）=U<G'，G' - 0.
[0065] 該攻擊的沖突概率約為2^6。
[0066] 新鮮值中可預(yù)測(cè)的非重復(fù)性由16位的呵管理，而不可預(yù)測(cè)部分由管理。
[0067] 再參考附圖，圖3所示為服務(wù)器和客戶(hù)端之間握手期間的步驟。它描述了輕型雙 向認(rèn)證及密鑰管理算法，其中表示客戶(hù)端，而g表示服務(wù)器。在認(rèn)證過(guò)程開(kāi)始之前，在供 給階段，2>1巧g之間線(xiàn)下共享密碼丫i= {0,1} 128。然后認(rèn)證過(guò)程W啟動(dòng)會(huì)話(huà)開(kāi)始，其中客 戶(hù)端發(fā)送'肥化〇'，#D|給服務(wù)器g，300。在該里，為唯一的客戶(hù)端設(shè)備ID。一旦會(huì) 話(huà)啟動(dòng)，服務(wù)器g通過(guò)向客戶(hù)端發(fā)送詢(xún)問(wèn)碼^{化（於?Ki 應(yīng)答，302,其中， ki，noncei= (0，1}-128和消息的大小為256位?？蛻?hù)端解密該詢(xún)問(wèn)碼，并通過(guò)發(fā)送另一包 括noncei和額外nonce2的詢(xún)問(wèn)碼應(yīng)答服務(wù)器。(riotie臣i?扔|巧〇巧《?2)}，304， 為客戶(hù)端應(yīng)答及詢(xún)問(wèn)。在服務(wù)器端，服務(wù)器核驗(yàn)noncei并通過(guò)發(fā)送通過(guò)ki加密為AES{:丫 1，(nonces|ki)}的nonces應(yīng)答客戶(hù)端，306。一旦客戶(hù)端和服務(wù)器驗(yàn)證所述新鮮值，并且完成 認(rèn)證，客戶(hù)端發(fā)送數(shù)據(jù)Pi到服務(wù)器，作為AES{k1，（Pi)}，308。
[0068] 再參考附圖，圖4和圖5表示在本發(fā)明的系統(tǒng)嵌入到已存在的應(yīng)用層協(xié)議之后的 修改的CoAP消息格式，400,分別作為提出的一般方案的示例應(yīng)用W及傳感器設(shè)備（客戶(hù) 端）和服務(wù)器之間的示例性握手認(rèn)證。
[0069] 典型的CoAP交互模式類(lèi)似于HTTP客戶(hù)端/服務(wù)器模式并且為REST化1。但與 HTTP不同的是，CoAP通過(guò)基于數(shù)據(jù)報(bào)的傳輸，如UDP，異步地進(jìn)行交換。通常，CoAP包括四 種類(lèi)型的消息；可確認(rèn)、不可確認(rèn)、確認(rèn)及復(fù)位。該些消息根據(jù)方式或者響應(yīng)碼攜帶請(qǐng)求或 應(yīng)答。
[0070] 本發(fā)明公開(kāi)的認(rèn)證方案可被整合為嵌入CoAP的REST化1有效負(fù)載。從圖5中可 W觀察到，具有可確認(rèn)（CON)數(shù)據(jù)傳輸模式的POST方法可用于實(shí)現(xiàn)傳感器設(shè)備（客戶(hù)端） 和服務(wù)器之間的雙向認(rèn)證。在CoAP報(bào)頭引入新的字段"AUTH"，從而實(shí)現(xiàn)安全（認(rèn)證）模 式，400。該字段采用表示關(guān)鍵選擇類(lèi)的未使用選項(xiàng)。另一名為"AUTH_MSG_TYPE"的選項(xiàng)連 同"AUTH"也被引入，指示用于創(chuàng)建認(rèn)證會(huì)話(huà)的不同消息。
[0071] CoAP報(bào)頭的該選擇字段攜帶CoAP消息的選擇性請(qǐng)求/應(yīng)答特征。本發(fā)明定義的 字段如下：
[007引 oAUTH;表示認(rèn)證/禁用認(rèn)證模式的啟動(dòng)。該字段的值可W為是或否。
[007引 oAUTH_MSG_TYPE;此字段可W是"0"或"1"，其中 0 =auth_initW及 1 = "response_against_challenge"。
[0074] 當(dāng)設(shè)置"AUTH=是"，可使用報(bào)頭中的常量"Token"值維持認(rèn)證會(huì)話(huà)，在認(rèn)證階段 用于相關(guān)的消息交換。
[0075] 參考圖4和圖5,執(zhí)行下列步驟W將CoAP嵌入認(rèn)證：
[0076] 0開(kāi)始，傳感器網(wǎng)關(guān)發(fā)送CON模式的POST消息到服務(wù)器認(rèn)證URI，其中AUTH選項(xiàng) 字段為真，AUTH_MSG_TYPE值為"auth_init"，即"0"，還發(fā)送有效負(fù)載600中的"設(shè)備標(biāo)識(shí) 符"。
[0077] 0服務(wù)器從有效負(fù)載中獲得設(shè)備標(biāo)識(shí)符，并且在接收到選項(xiàng)"AUTH"及AUTH_MSG_ TYPE的"auth_init"值之后，確定與該設(shè)備標(biāo)識(shí)符相關(guān)的預(yù)共享密碼。然后，它產(chǎn)生隨機(jī)數(shù) (nonce_l)和密鑰化)。服務(wù)器利用共享密鑰生成加密的有效負(fù)載。
[007引 0服務(wù)器用應(yīng)答碼答復(fù)客戶(hù)端，表示已經(jīng)創(chuàng)建新的資源。答復(fù)中的URI指出了針 對(duì)認(rèn)證的整個(gè)握手的臨時(shí)會(huì)話(huà)ID。如果為無(wú)效的設(shè)備標(biāo)識(shí)符，則服務(wù)器發(fā)送應(yīng)答碼"未認(rèn) 證"。該加密的有效負(fù)載附帶地或者單獨(dú)地發(fā)送到客戶(hù)端，602。
[0079]0客戶(hù)端解密來(lái)自服務(wù)器的應(yīng)答并獲得nonce_l及"K"。它產(chǎn)生隨機(jī)數(shù)（nonce_2)， 然后使用密鑰"K"生成加密的有效負(fù)載。它使用具有選項(xiàng)字段"AUTH"的POST消息發(fā)送有 效負(fù)載，并且AUTH_MSG_TYPE的值為 <response_against_challenge'，并且與上一個(gè)POST 消息具有相同的標(biāo)記值，604。
[0080] 0維持一個(gè)密鑰刷新定時(shí)器W刷新會(huì)話(huà)。（在CoAP的情況下，該個(gè)值一定要大于 MAX_RETRANSMIT_COUNT*MAX_RETRANSMISSION_TIMEOU。
[00川 o服務(wù)器使用"K"解密在頭部具有上述選項(xiàng)值的上述POST的有效負(fù)載，并查看接 收到的隨機(jī)數(shù)。如果隨機(jī)數(shù)與之前的值（步驟2中產(chǎn)生的值）相同，則服務(wù)器發(fā)送具有應(yīng) 答碼"已改變"的應(yīng)答，表示認(rèn)證資源改變，否則發(fā)送"未認(rèn)證"，606。
[0082] 圖5中使用的符號(hào)如下所述；
[0083] 1])。;傳感器網(wǎng)關(guān)5。及服務(wù)器S之間的共享密碼
[0084] K"| T;傳感器網(wǎng)關(guān)5。與服務(wù)器在T th會(huì)話(huà)中的密鑰交換 [00化]<S?！?；Sn的唯一的傳感器設(shè)備/網(wǎng)關(guān)ID。
[0086] AES(.)K;使用密鑰K在明文中的AES操作
[0087] nonce貨nonce, =服務(wù)器初始化的隨機(jī)數(shù)
[008引 nonceg^ =傳感器網(wǎng)關(guān)/客戶(hù)端初始化的隨機(jī)數(shù)
[0089] ?。;傳感器網(wǎng)關(guān)5。的傳感器數(shù)據(jù)
[0090] 在認(rèn)證階段結(jié)束并且安全通道創(chuàng)建完成之后，客戶(hù)端可選擇性地W完全開(kāi)環(huán)的模 式通信，同時(shí)更新服務(wù)器中的一些資源，從而使得客戶(hù)端表現(xiàn)出對(duì)服務(wù)器應(yīng)答的不關(guān)屯、。 [oow] 在本發(fā)明的系統(tǒng)的一個(gè)實(shí)施例中，CoAP用于NON(非可靠）模式，并且引入選項(xiàng)字 段（例如無(wú)應(yīng)答），表示服務(wù)器不需要應(yīng)答資源運(yùn)行的狀態(tài)。因此，網(wǎng)絡(luò)的負(fù)載會(huì)降低。該 '無(wú)應(yīng)答'字段值為"0"或"1"，0表示服務(wù)器需要應(yīng)答該狀態(tài)，1表示服務(wù)器不需要應(yīng)答該 狀態(tài)。
[0092] 再參考附圖，圖6表示將本發(fā)明的系統(tǒng)作為附加認(rèn)證層與DTLS，如安全層500融 厶 口 〇
[0093] 再參考附圖，圖7表示使用預(yù)共享密鑰模式（PSK)的安全會(huì)話(huà)啟動(dòng)的DTLS握手的 時(shí)序圖，而圖8表示將本發(fā)明的方法整合到DTLS框架中，結(jié)果在創(chuàng)建安全連接之前，帶來(lái)具 有預(yù)共享密碼及衍生密鑰的修改的DTLS握手。每一個(gè)握手消息被預(yù)共享密碼或者衍生的 密鑰K加密。圖7中帶有的元素表示依賴(lài)情境的消息。圖8描述了消息交換與圖3表 示的服務(wù)器和客戶(hù)端握手期間設(shè)及的步驟之間的映射。參考圖7和圖8,可W得出本發(fā)明的 系統(tǒng)可W將握手的次數(shù)從6次減少到4次。
[0094] W下為本發(fā)明帶來(lái)的有益技術(shù)效果：
[0095] 根據(jù)如上所描述根據(jù)本發(fā)明的，計(jì)算機(jī)實(shí)施的在數(shù)據(jù)報(bào)傳輸中用于輕型認(rèn)證的系 統(tǒng)和方法具有多個(gè)有益技術(shù)效果，包括但不僅限于其實(shí)現(xiàn)了 ：
[0096] ?一種系統(tǒng)需求減少的系統(tǒng)，原因在于其基于嵌有有效負(fù)載的對(duì)稱(chēng)密鑰的認(rèn)證W 及由會(huì)話(huà)密鑰刷新定時(shí)器管理的集成密鑰；
[0097] ?一種用于保護(hù)資源受限傳感器設(shè)備的理想系統(tǒng)；
[009引 ?一種可集成有傳輸層安全機(jī)制的系統(tǒng)，如集成DTLS，從而加強(qiáng)已有的DTLS方 案，同時(shí)通過(guò)減少交換的數(shù)量，使其變得更輕型；
[0099] ?一種可W將應(yīng)用協(xié)議作為嵌入有效負(fù)載的認(rèn)證方案的系統(tǒng)；
[0100] ?一種可W與如CoAP的受限設(shè)備應(yīng)用層整合的系統(tǒng)；
[010U ?-種通過(guò)引入新的具有應(yīng)用層協(xié)議的報(bào)頭選項(xiàng)允許CoAP開(kāi)環(huán)通信的系統(tǒng)，從 而在實(shí)現(xiàn)認(rèn)證后優(yōu)化資源使用率；W及
[0102] ?一種可普遍滿(mǎn)足一般網(wǎng)絡(luò)/通信系統(tǒng)的認(rèn)證需求的系統(tǒng)。
[0103] 上文對(duì)特定實(shí)施例地描述全面的披露了本發(fā)明實(shí)施例的一般特性，通過(guò)運(yùn)用現(xiàn)有 知識(shí)，可W很容易地在不背離本發(fā)明一般思想的情況下，對(duì)該實(shí)施例進(jìn)行修改并且/或者 適用該特定實(shí)施例的多個(gè)應(yīng)用，因此，該些適用及修改應(yīng)該并且意在落入本發(fā)明實(shí)例的等 同保護(hù)范圍之內(nèi)。應(yīng)該理解，本文采用的用詞和術(shù)語(yǔ)都是為了描述目的，不做限制用途。因 此，雖然本文W優(yōu)選實(shí)施例的形式描述了實(shí)施例，但是本領(lǐng)域技術(shù)人員可W理解，本文中的 實(shí)施例可在文中描述的實(shí)施例的思想和范圍內(nèi)做出修改。
【主權(quán)項(xiàng)】
1. 一種計(jì)算機(jī)實(shí)施的服務(wù)器與客戶(hù)端之間數(shù)據(jù)報(bào)傳輸雙向認(rèn)證系統(tǒng)，所述系統(tǒng)包括系 統(tǒng)處理器，并包括： i.