【正文】 的冗余位縮短整個(gè)網(wǎng)絡(luò)的生命周期。Granjal評(píng)估了帶有CoAP的DTLS在安全通信中的性能。他們注意到稀缺性負(fù)載空間在需要更大的有效載荷的應(yīng)用程序中會(huì)有問題。作為一種替代方法，他們建議在其他層使用像IPsec這樣的壓縮形式來保證安全。在最近的研究中，Keoh 討論了保護(hù)以IP連接并使用DTLS協(xié)議的物聯(lián)網(wǎng)的安全的意義，并提出了一個(gè)安全的網(wǎng)絡(luò)架構(gòu)，用延長的DTLS對(duì)單播和多播密鑰進(jìn)行訪問和管理。上述解決方案要么對(duì)物聯(lián)網(wǎng)中的TLS或DTLS的使用進(jìn)行了評(píng)估，要么對(duì)破壞端到端安全的當(dāng)前架構(gòu)進(jìn)行評(píng)估。本文通過使用6LowPAN頭壓縮機(jī)制來減少物聯(lián)網(wǎng)中DTLS的開銷。我們提出了設(shè)計(jì)思想以減少雙向的基于證書的DTLS握手的能源消費(fèi)。我們提出的建議如下：預(yù)先驗(yàn)證可靠的6BR中的證書。全面恢復(fù)會(huì)話以避免重新握手。資源有限的設(shè)備的所有者來承擔(dān)握手任務(wù)。在物聯(lián)網(wǎng)中驗(yàn)證基于證書的可行性的工作與這一工作是互補(bǔ)的。為使基于證書的相互握手更高效，我們計(jì)劃把DTLS報(bào)頭壓縮與這些想法集合起來。最近，類似于NHC的通用頭壓縮（GHC）也被定義成可以允許上層頭壓縮。6LowPANGHC對(duì)于所有的頭和類似于頭的結(jié)構(gòu)是一個(gè)通用的壓縮方案，但是一個(gè)低效的方法。它是我們的解決方案的替代方法，在將來的工作中，我們計(jì)劃把我們的6LowPANNHC與6LowPANGHC做一個(gè)比較。三、背景由于物聯(lián)網(wǎng)的異質(zhì)性，將有資源限制的設(shè)備安全而有效的連接起來是一項(xiàng)很有挑戰(zhàn)性的工作。目前，互聯(lián)網(wǎng)工程任務(wù)組正在標(biāo)準(zhǔn)化不同的協(xié)議，如CoAP，6LowPAN，低電力有損網(wǎng)絡(luò)中的IPv6路由協(xié)議，以使這些協(xié)議可以應(yīng)用在物聯(lián)網(wǎng)中。本文的重點(diǎn)是讓用CoAP協(xié)議的物聯(lián)網(wǎng)設(shè)備之間進(jìn)行安全有效的溝通。在本章中我們突出了在輕量級(jí)CoAP發(fā)展中使用的技術(shù)，即物聯(lián)網(wǎng)的HTTP變體。A、CoAP和DTLS CoAP是運(yùn)行在不可靠UDP協(xié)議上的網(wǎng)絡(luò)協(xié)議，它最初是為物聯(lián)網(wǎng)設(shè)計(jì)的。CoAP是最常用的同步Web協(xié)議的變種，如HTTP，是專為受限制的設(shè)備和機(jī)器與機(jī)器之間的溝通設(shè)計(jì)的。然而，盡管CoAP提供了與HTTP類似的REST接口，但與現(xiàn)在物聯(lián)網(wǎng)中它的變體相比，CoAP更注重輕量級(jí)和成本效益。為了保護(hù)CoAP傳輸，建議數(shù)據(jù)報(bào)TLS(DTLS)作為主要的安全協(xié)議，類似于TLS保護(hù)HTTP(HTTPs)，安全的DTLS CoAP協(xié)議稱為CoAPs。然后就可以通過如下的CoAPs協(xié)議安全地訪問物聯(lián)網(wǎng)設(shè)備中的web資源：coaps://myIPv6Address:port/MyResource 我們給出了DTLS協(xié)議的簡要概述來作為DTLS壓縮機(jī)制的基礎(chǔ)。通過對(duì)傳輸層和應(yīng)用層的操作，DTLS保證了單個(gè)機(jī)器上不同程序之間的E2E的安全。DTLS包含兩層：底層包含記錄協(xié)議，上層要么包含握手，警告和ChangeCIPherSpec，要么包含應(yīng)用數(shù)據(jù)。ChangeCIPherSpec在握手過程中使用，這僅僅表明，記錄協(xié)議應(yīng)該通過新密碼套件和安全協(xié)商鑰匙來保護(hù)后續(xù)信息。DTLS使用警報(bào)協(xié)議來實(shí)現(xiàn)不同DTLS之間錯(cuò)誤消息的傳送。圖2顯示了在IP/UDP數(shù)據(jù)報(bào)中DTLS的消息結(jié)構(gòu)。記錄協(xié)議是上層協(xié)議的載體。記錄頭包含其他內(nèi)容類型和片段字段?；趦?nèi)容類型的值，片段字段要么包含握手協(xié)議，警告協(xié)議和ChangeCIPherSpec協(xié)議，要么包含應(yīng)用數(shù)據(jù)。一旦握手過程完成，記錄頭主要是負(fù)責(zé)用密碼保護(hù)上層協(xié)議或應(yīng)用數(shù)據(jù)。記錄協(xié)議的保護(hù)包括機(jī)密性、完整性和真實(shí)性的保護(hù)。DTLS記錄是一個(gè)相當(dāng)簡單的協(xié)議而握手協(xié)議是一個(gè)復(fù)雜的過程，它包含以異步的方式大量交換的消息。圖3給出了完整的握手過程。握手消息，通常在航班、談判安全密鑰、密碼套件和壓縮方法中使用。本文的范圍只限于報(bào)頭壓縮，而不包括處理密碼記錄和握手協(xié)議。詳細(xì)的握手消息我們參考TLS和DTLS消息。B、6LoWPAN 6LoWPAN標(biāo)準(zhǔn)定義了與IPv6相關(guān)的WSNs中的IPv6數(shù)據(jù)報(bào)的標(biāo)題壓縮和分化機(jī)制的，也稱為6LowPAN網(wǎng)絡(luò)。壓縮機(jī)制包括IP頭壓縮(IPHC)和下一個(gè)頭壓縮(NHC)。IPHC加密可以在單跳網(wǎng)絡(luò)中將IPv6頭長度壓縮至2字節(jié)，在多跳網(wǎng)絡(luò)中壓縮至7字節(jié)（1字節(jié)IPHC、1字節(jié)發(fā)送、1字節(jié)跳限制，2字節(jié)源地址，2字節(jié)目的地地址）。在IPHC中的其他加密比特是NH比特，它在設(shè)置時(shí)顯示下一個(gè)頭是用NHC壓縮。NHC是用來加密IPv6的擴(kuò)展頭和UDP頭。NHC的大小是一個(gè)多重的八位字節(jié)（主要是一個(gè)八位字節(jié)），它包含可變長度ID比特和一個(gè)特定的頭編碼比特。有些協(xié)議是UDP負(fù)載的一部分，有著類似于IP和UDP 的頭結(jié)構(gòu)。例如DTLS，IKE。因此，值得推廣6LowPAN頭壓縮機(jī)制來壓縮這些協(xié)議頭。6LowPAN標(biāo)準(zhǔn)的定義了NHC編碼，可用于UDP頭壓縮，但不能用于上層。需要一個(gè)新的NHC，因?yàn)樵贜HC中沒有給UDP的NH位，這表明UDP負(fù)載也壓縮了。在第四部分，我們提供了6LowPANDTLS的集合和6LowPAN NHCs來壓縮DTLS。如圖1所示是頭壓縮在6LowPAN網(wǎng)絡(luò)中應(yīng)用。例如，在有限的節(jié)點(diǎn)和6LowPAN邊界路由器之間的應(yīng)用。6BR是用在網(wǎng)絡(luò)和英特網(wǎng)之間轉(zhuǎn)發(fā)消息前，來壓縮/解壓縮或者片段化/重新組裝它們之間的消息。在這種物聯(lián)網(wǎng)設(shè)備中，CoAP使得設(shè)備可以與網(wǎng)絡(luò)主機(jī)之間安全通信，例如標(biāo)準(zhǔn)的電腦和智能電話等，它支持CoAPs協(xié)議。為了適應(yīng)安全協(xié)議，例如在資源受限的物聯(lián)網(wǎng)中的DTLS，把6LowPAN頭壓縮機(jī)制應(yīng)用到這些協(xié)議中也是非常有益的。第四節(jié)里我們提出了DTLS的6LowPAN頭壓縮機(jī)制。以DTLS標(biāo)準(zhǔn)來設(shè)計(jì)這些報(bào)頭壓縮是非常重要的，要能夠在傳統(tǒng)的互聯(lián)網(wǎng)上與現(xiàn)有的和新的DTLS主機(jī)之間互操作。四、DTLS壓縮DTLS頭壓縮類似于IPHC，僅在6LowPAN網(wǎng)絡(luò)中應(yīng)用，如在傳感器節(jié)點(diǎn)和6BR中使用。這是因?yàn)镈TLS報(bào)頭是UDP負(fù)載的一部分，而且路由所需的所有信息已經(jīng)在IP層提取。在本章中除了描述DTLS的6LowPAN頭壓縮，我們?cè)敿?xì)介紹了如何以符合標(biāo)準(zhǔn)的方式將壓縮的DTLS連接到6 LowPAN。A、DTLS6LowPAN 為了將6LowPAN頭壓縮機(jī)制應(yīng)用于壓縮UDP負(fù)載中的頭，我們要么需要在6LowPAN協(xié)議中修改當(dāng)前UDP中的NHC編碼，要么需要給UDP定義一個(gè)不同于ID位的新的NHC。第一個(gè)解決方案需在當(dāng)前標(biāo)準(zhǔn)中修改，因此不是一個(gè)有利的解決方案。在這篇論文中我們用了第二種方案，它是6LowPAN標(biāo)準(zhǔn)的延伸，有一個(gè)類似的方法適合于區(qū)分NHC和GHC。UDP中NHC的ID位11110，與6LowPAN中定義的標(biāo)準(zhǔn)一樣，表明UDP負(fù)載不壓縮。定義ID位11011表明UDP負(fù)載用6LowPANNHC壓縮。ID位1101目前在6LowPAN標(biāo)準(zhǔn)中還未定義。圖4給出了我們提出的UDP中的NHC，它允許UDP負(fù)載的壓縮。在我們的例子中，UDP負(fù)載包含用6LowPANNHC壓縮的DTLS頭。B、用于記錄頭和握手頭的6LowPANNHC記錄協(xié)議 在使用DTLS的設(shè)備的生命周期中，給發(fā)送的每個(gè)數(shù)據(jù)包增加了13個(gè)字節(jié)長的頭字段，另一方面，握手協(xié)議，在握手消息中增加了12字節(jié)的頭。我們提出6LowPANNHC來壓縮記錄協(xié)議和握手協(xié)議，并分別把頭長度減少到3~5個(gè)字節(jié)。在所有情況下，記錄頭仍是未加密的。因此，總是用在這章中解釋的機(jī)制來壓縮。為了向記錄和握手頭提供頭壓縮，我們考慮兩種情況。在第一種情況中，記錄頭的片段（見第三部分）包含握手消息，我們用加密字節(jié)來壓縮記錄和握手頭消息，并且給出了記錄+握手中6LowPANNHC的定義。在第二種情況下，我們給記錄頭定義了6LowPANNHC（6LowPANNHCR），與第一種情況不同的是，在記錄頭中的片段是應(yīng)用數(shù)據(jù)而不是握手消息。我們成功實(shí)現(xiàn)了在DTLS握手后應(yīng)用6LowPANNHCR，并且對(duì)隨后的消息進(jìn)行加密和完整性保護(hù)。圖2a給出了記錄+握手頭和記錄頭的6LowPANNHC加密。加密為有以下功能：前4位代表的ID字段用來區(qū)分 6LowPANNHCRHS和其他編碼，而且符合 6LowPANNHC編碼方案。在 6LoWPANNHCRHS情況下我們把ID位設(shè)置到了1000，在 6LoWPANNHCR情況下ID位設(shè)置到了1001。版本（V）：如果是0，是最新的DTLS，省略了字段。如果是1，版本字段進(jìn)行內(nèi)聯(lián)。時(shí)代（EC）：如果是0，使用了八位表示時(shí)代，最左邊的八位省略。如果是1，所有16為進(jìn)行內(nèi)聯(lián)。在大多數(shù)情況下實(shí)際年代要么是0要么是1。所以通常使用8位表示年代，這樣允許更大的空間。序列號(hào)（SN）：序列號(hào)包含48位，有些事前導(dǎo)0。如果序列號(hào)設(shè)為0，就用了16位的序列號(hào)，并且左邊的32位省略了。如果是1，所有的48位用于內(nèi)聯(lián)。如圖5a所示，在 6LoWPANNHCR情況下，我們的SN設(shè)為2位，這樣可以更高效的壓縮序列號(hào)字段。如果SN=00，就用了16位的序列號(hào)，并且左邊的32位省略了。如果SN=01，就用了32位的序列號(hào)并且最左邊的32位省略。如果SN=01，就用了32位的序列號(hào)，并且最左邊的16位省略了。如果SN=10，就用了24位的序列號(hào)，并且最左邊的24位省略了。如果SN=11，所有的48位序列號(hào)用于內(nèi)聯(lián)。片段（F）：如果F=0，則握手消息沒有片段化，并且省略了fragment_offset 和 fragment_length字段。這是常見的情況，如果握手消息短于最大記錄長度時(shí)就會(huì)發(fā)生。如果F=1，fragment_offset 和 fragment_length字段用于互聯(lián)。在記錄頭上，content_ type字段總是用于內(nèi)聯(lián)。記錄頭中的長度字段總是省略，因?yàn)榭梢詮妮^低層推算出：或者從 6LoWPAN的頭，或者從 IEEE 。我們必須從低層到高層解壓layerwise，直到完全解壓出UDP報(bào)頭。然后就可以知道UDP有效負(fù)載的長度并可以計(jì)算出DTLS負(fù)載長度。由于我們希望在受限的環(huán)境中每個(gè)UDP包只有一個(gè)DTLS記錄頭，所以記錄頭的長度字段也省略了。當(dāng) 6LoWPAN中的源裝置在每個(gè)UDP包中發(fā)送一個(gè)DTLS記錄時(shí)，傳統(tǒng)網(wǎng)絡(luò)側(cè)會(huì)有典型的目的裝置在一個(gè)UDP包中傳送多個(gè)DTLS記錄頭。然而，當(dāng)6BR對(duì)傳入的包執(zhí)行壓縮/解壓時(shí)，有可能在6LoWPAN網(wǎng)絡(luò)中給出這些包的路由之前，對(duì)每個(gè)UDP包執(zhí)行一個(gè)DTLS記錄。C、6LoWPANNHC for ClientHello 我們提出了客戶端友好型的消息6LoWPANNHC（6LoWPANNHCC）。在握手過程中會(huì)發(fā)送兩次客戶端友好型消息，第一次沒有cookie而第二次有服務(wù)器的cookie。圖5b給出了用6LoWPANNHC對(duì)客戶端友好型消息進(jìn)行加密的過程。每一個(gè)壓縮頭字段的功能描述如下： 6LoWPANNHCCH中前四位設(shè)為1010用來表示ID字段。會(huì)話ID（SI）：如果SI=0，session_id不可用，并將這一字段和8位的前綴長度字段省略。在DTLS協(xié)議中如果沒有字段可用，或者用戶想生成新的安全參數(shù)，那么session_id就是空的。只有在DTLS客戶想要恢復(fù)舊會(huì)話時(shí)，才會(huì)使用ClientHello消息。真正的ClientHello中session_id字段包含032字節(jié)。然而，它的前綴中總是有一個(gè)8位的字段來表示session_id的大小。如果SI=1，session_id字段用于內(nèi)聯(lián)。Cookie（C）如果C=0，cookie字段不可用，省略這一字段和前綴8位。在ClientHello中真正的cookie字段包含1255字節(jié)。然而，它總是有8位來表示cookie的長度。如果C=1，cookie字段用于內(nèi)聯(lián)。密碼套件（CS): 如果CS=0，使用了CoAP默認(rèn)的（強(qiáng)制性）支持自動(dòng)的鍵管理的密碼套件，并且這個(gè)字段和前綴16位被省略了。在當(dāng)前的CoAP草稿中，TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8是一個(gè)強(qiáng)制性的密碼套件。真正的密碼套件字段包含22^16?1字節(jié)。并且在前綴中包含16字節(jié)來表示 cIPher_suites的大小。如果C=1，cipher_suites用于內(nèi)線互聯(lián)。壓縮方法（CM）：如果CM=0，就為默認(rèn)的壓縮方法，例如，用到了COMPRESSION_NULL，省略這個(gè)字段和前綴8位字段。實(shí)際上壓縮方法字段包含12^81字節(jié)。它總是在前綴八位包含壓縮方法的大小。如果CM=1，那么壓縮方法字段用于內(nèi)線互聯(lián)。在ClientHello中隨機(jī)字段總是用于內(nèi)線互聯(lián)并且總是省略版本字段。版本字段包含的值與DTLS記錄頭中的值一樣。在TLS/SSL情況下，定義版本字段來讓一個(gè)TLS的客戶指定一個(gè)舊版本以兼容SSL客戶機(jī)，而這在實(shí)際中很少用到。當(dāng)前所有的Web瀏覽器在記錄和ClientHello中使用相同的TLS版本。（改編自TLS ）提到客戶在ClientHello消息中發(fā)送最新的支持版本。所有DTLS版本()的ClientHello消息相兼容。如果客戶機(jī)不兼容這種版本，那么ServerHello消息將包含支持的版本。如果客戶不能夠處理服務(wù)器的版本，它將給出終止與協(xié)議版本連接的警報(bào)。使用 6LoWPANNHCCH，通常只傳送 ClientHello消息中的隨機(jī)字段，而省略所有其他字段。同時(shí)，cookie會(huì)包含可壓縮的字段。圖6給出了一個(gè)包含ClientHello且未壓縮的IP/UDP數(shù)據(jù)報(bào)。圖7給出了我們提出的壓縮DTLS，它包含ClientHello消息。在應(yīng)用IPHC和 6LoWPANNHC頭壓縮后，數(shù)據(jù)報(bào)的尺寸是顯著降低了。D、服務(wù)器友好型 6LoWPANNHC 我們提出了SeverHello消息的 6LoWPANNHC（6LoWPANNHCSH）。SeverHello與ClientHello除了密碼套件和壓縮方法字段分別位16和8位外，它們非常相似。圖5給出了用 6LoWPANNHC 加密的ServerHello消息。每個(gè)壓縮頭的功能描述如下：前6 LoWPANNHCSH中前四位設(shè)置為1011代表ID字段。版本（V）：為了在最初版本的握手中避免談判，DTLS 。如果V設(shè)為0。如果V設(shè)為1，那么版本字段用于內(nèi)線互聯(lián)。會(huì)話（ID），密碼套件（CS）和壓