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