外文翻译Lithe物联网中的轻量级安全CoAP协议.doc

Lithe:物联网中的轻量级安全CoAP协议摘要：物联网支持广泛的包含潜在驱动和传感任务的应用场景，例如，在电子健康领域。为了在应用层通信，资源受限的设备要能够使用资源受限的应用协议（CoAP），目前互联网工程组正在使这项协议标准化。为了保护感知信息的传送，安全的资源受限协议授权使用数据报传输层安全协议（DTLS）作为底层安全协议来进行身份认证和保密通信。然而，数据包传输层安全协议最初是用在比较强大的设备上的，这些设备通过可靠的高带宽的链路来进行通信。在这篇论文中我们提出了Lithe物联网中数据报传输层安全协议和资源受限的应用协议的集成协议。通过Lithe，另外我们利用低功率无线个人区域网络IPV6协议（6 LoWPAN），提出了一个新颖的DTLS头压缩计划，旨在显著降低能源消耗。最重要的是我们提出的DTLS头压缩方案不威协DTLS提供的端到端的安全属性。同时，它在保持DTLS标准性的情况下，大大降低了传播的数量字节。我们在Contiki操作系统下基于DTLS来评估了我们的方法。评估结果表明该方案在包的大小，能量消耗，处理时间方面有了显著改善，而且能够在压缩DTLS时得到全网响应。索引词：CoAP，DTLS，CoAPs，6LoWPAN， security， IoT一、简介低功率无线个人区域网络IPV6协议（6 LowPAN）允许使用低功耗的IP网络和有损耗的无线传感器网络，例如无线传感网（WSNs）。这样的IP连接的智能设备正成为互联网的一部分，因此形成了物联网或者严格来说形成了IP连接的物联网。然而由于TCP的拥塞控制算法，使得它在无线网络中的性能很差，低功率无线电和传感网络中的损耗进一步恶化了它的性能。因此物联网中主要使用无连接的UDP。此外。HTTP主要是在TCP基础上运行，它在损耗和受限环境下效率低下。IETF工作在无连接的轻量级的CoAP上，CoAP是物联网中新提出的协议。它是为了满足特定需求，如在资源受限下支持简单，低开销，多播传输。当物体连接到不可信的网络时，安全就尤其重要了。例如，医疗监测代表一个典型的对安全敏感的应用场景。这里，一种智能装置，例如，如胰岛素，可能被附加到病人的身体并向后端服务互联网定期报告病人的情况。在紧急情况下，医生还可以向病人的身体即时注射治疗药物。为了实现自动键管理、数据加密、完整性保护和身份验证，CoAP提出使用数据报传输层安全(DTLS)作为安全协议。DPLS支持的CoAP被称为安全CoAP（CoAPs）。DTLS是一个健壮的协议，它需要大量的信息交流来建立一个安全的会话。虽然DTLS支持多种对等认证的加密原语和负载保护，但它最初用于长度不是一个关键因素的网络场景。因此，它限制物联网设备，使用DTLS协议就会很低效。为应对资源约束和基于网络的IEEE 802.15.4的大小限制，定义了6 LoWPAN头压缩机制。6 LoWPAN标准已经定义了IP报头的标题压缩格式，IP扩展报头和UDP报头。我们相信把6 LoWPAN报头压缩机制应用于压缩其他有明确的头字段的协议非常有益。在这篇文章中我们通过用6 LoWPAN报头压缩机制来压缩底层DTLS协议并提出了轻量级 CoAPs。我们命名轻量级6 LoWPAN为压缩的CoAPs Lithe。DTLS头的目的是双重压缩。首先，由于通信比计算需要更多的能量，所以可以通过减少消息大小来提高能源效率。第二，当数据报大小大于链路层MTU时，避免应用6 LoWPAN碎片。从安全角度来看，由于6 LoWPAN禁不住碎片攻击，所以只要有可能，避免碎片是非常重要的。压缩的DTLS保证了Lithe中的6 LoWPAN主机和典型的应用未压缩的CoAPs网络主机之间的端到端安全。图1显示了一个典型的物联网设备，包含了应用CoAPs的节点的6 LoWPAN网络通过6LowPAN边界路由器(6BR)与互联网连接。据我们所知，我们是第一个提出用6LowPAN机制压缩DTLS并使轻量级CoAPs应用于物联网的。我们在Contiki操作系统中实现了DTLS头压缩机制。这篇论文的主要贡献有：为了增加DTLS的适用性，我们提出了新颖的标准的DTLS压缩机制，在此基础上可以将CoAPs应用于受限的设备。我们在一个应用于物联网的操作系统上实现压缩的DTLS并且在硬件上进行了评估。结果定量的表明，与未压缩的CoAP/DTLS相比，Lithe在很多方面都很高效。文章的余下部分是这样安排的。我们首先在第二章总结了相关工作。第三章对所用到的技术做了简要的概述。第四章，我们介绍了DTLS头压缩机制。第五章，我们给出了实现。第六章，论述了网络设置并讨论评估结果。最后在第七章做出总结。二、相关工作在传统互联网中提供端到端的安全通信是一个广泛的研究领域。然而，相对来说，在端到端安全研究中很少考虑到了6LoWPANs。设备的资源约束和无线链接的自然损耗是阻碍把端到端安全应用到6LoWPANs的主要原因。最近，有组织在分析基于IP的物联网的安全性挑战，为满足资源有限的设备的需求，该组织还提出了改善或修改标准IP安全协议的方案。在相关工作的讨论中，我们专注于旨在实现物联网端到端安全的方案。先前，我们提出了一个头压缩方法，它通过用IPsec来保证6LowPAN中的节点与因特网中的主机之间的通信安全。我们定义下一个头压缩(NHC)编码来压缩认证头(AH)和封装安全有效载荷(ESP)的扩展报头。Jorge扩展了我们的解决方案，其中包括IPsec隧道模式。他们在微型操作系统上实施和评估了他们的建议。IPsec安全服务在特定的机器上运行的所有应用程序之间共享。尽管我们用6LowPAN压缩的IPsec可以用来在网络层提供轻量级的E2E安全，但它最初不是为像HTTP和CoAP这样的网络协议设计的。TLS或DTLS web协议是常见的安全解决方案。TLS运行在TCP上，而在UDP基础上 6LowPAN网络优先。 Brachmann提出了TLS-DTLS映射来保障物联网安全。然而，这需要有可靠的6BR和在6BR间歇时的端到端安全。 Kothmayr调查了在可信平台模块上用DTLS来获得对RSA算法的硬件支持。然而，他们利用了DTLS，而没有用任何压缩方法，这会造成DTLS消息中的冗余位缩短整个网络的生命周期。 Granjal评估了带有CoAP的DTLS在安全通信中的性能。他们注意到稀缺性负载空间在需要更大的有效载荷的应用程序中会有问题。作为一种替代方法，他们建议在其他层使用像IPsec这样的压缩形式来保证安全。在最近的研究中， Keoh 讨论了保护以IP连接并使用DTLS协议的物联网的安全的意义，并提出了一个安全的网络架构，用延长的DTLS对单播和多播密钥进行访问和管理。上述解决方案要么对物联网中的TLS或DTLS的使用进行了评估，要么对破坏端到端安全的当前架构进行评估。本文通过使用6LowPAN头压缩机制来减少物联网中DTLS的开销。我们提出了设计思想以减少双向的基于证书的DTLS握手的能源消费。我们提出的建议如下：1、预先验证可靠的6BR中的证书。2、全面恢复会话以避免重新握手。3、资源有限的设备的所有者来承担握手任务。在物联网中验证基于证书的可行性的工作与这一工作是互补的。为使基于证书的相互握手更高效，我们计划把DTLS报头压缩与这些想法集合起来。最近，类似于NHC的通用头压缩（GHC）也被定义成可以允许上层头压缩。6LowPANGHC对于所有的头和类似于头的结构是一个通用的压缩方案，但是一个低效的方法。它是我们的解决方案的替代方法，在将来的工作中，我们计划把我们的6LowPAN-NHC与6LowPAN-GHC做一个比较。三、背景由于物联网的异质性，将有资源限制的设备安全而有效的连接起来是一项很有挑战性的工作。目前，互联网工程任务组正在标准化不同的协议，如CoAP，6LowPAN，低电力有损网络中的IPv6路由协议，以使这些协议可以应用在物联网中。本文的重点是让用CoAP协议的物联网设备之间进行安全有效的沟通。在本章中我们突出了在轻量级CoAP发展中使用的技术，即物联网的HTTP变体。A、 CoAP和DTLSCoAP是运行在不可靠UDP协议上的网络协议，它最初是为物联网设计的。CoAP是最常用的同步Web协议的变种，如HTTP，是专为受限制的设备和机器与机器之间的沟通设计的。然而，尽管CoAP提供了与HTTP类似的REST接口，但与现在物联网中它的变体相比，CoAP更注重轻量级和成本效益。为了保护CoAP传输，建议数据报TLS(DTLS)作为主要的安全协议，类似于TLS保护HTTP(HTTPs)，安全的DTLS CoAP协议称为CoAPs。然后就可以通过如下的CoAPs协议安全地访问物联网设备中的web资源：coaps:/myIPv6Address:port/MyResource我们给出了DTLS协议的简要概述来作为DTLS压缩机制的基础。通过对传输层和应用层的操作，DTLS保证了单个机器上不同程序之间的E2E的安全。DTLS包含两层：底层包含记录协议，上层要么包含握手，警告和ChangeCIPherSpec，要么包含应用数据。ChangeCIPherSpec在握手过程中使用，这仅仅表明，记录协议应该通过新密码套件和安全协商钥匙来保护后续信息。DTLS使用警报协议来实现不同DTLS之间错误消息的传送。图2显示了在IP/UDP数据报中DTLS的消息结构。 记录协议是上层协议的载体。记录头包含其他内容类型和片段字段。基于内容类型的值，片段字段要么包含握手协议，警告协议和ChangeCIPherSpec协议，要么包含应用数据。一旦握手过程完成，记录头主要是负责用密码保护上层协议或应用数据。记录协议的保护包括机密性、完整性和真实性的保护。DTLS记录是一个相当简单的协议而握手协议是一个复杂的过程，它包含以异步的方式大量交换的消息。图3给出了完整的握手过程。握手消息，通常在航班、谈判安全密钥、密码套件和压缩方法中使用。本文的范围只限于报头压缩，而不包括处理密码记录和握手协议。详细的握手消息我们参考TLS和DTLS消息。B、6LoWPAN6LoWPAN标准定义了与IPv6相关的WSNs中的IPv6数据报的标题压缩和分化机制的，也称为6LowPAN网络。压缩机制包括IP头压缩(IPHC)和下一个头压缩(NHC)。IPHC加密可以在单跳网络中将IPv6头长度压缩至2字节，在多跳网络中压缩至7字节（1字节IPHC、1字节发送、1字节跳限制，2字节源地址，2字节目的地地址）。在IPHC中的其他加密比特是NH比特，它在设置时显示下一个头是用NHC压缩。NHC是用来加密IPv6的扩展头和UDP头。NHC的大小是一个多重的八位字节（主要是一个八位字节），它包含可变长度ID比特和一个特定的头编码比特。有些协议是UDP负载的一部分，有着类似于IP和UDP 的头结构。例如DTLS，IKE。因此，值得推广6LowPAN头压缩机制来压缩这些协议头。6LowPAN标准的定义了NHC编码，可用于UDP头压缩，但不能用于上层。需要一个新的NHC，因为在NHC中没有给UDP的NH位，这表明UDP负载也压缩了。在第四部分，我们提供了6LowPAN-DTLS的集合和6LowPAN NHCs来压缩DTLS。如图1所示是头压缩在6LowPAN网络中应用。例如，在有限的节点和6LowPAN边界路由器之间的应用。6BR是用在网络和英特网之间转发消息前，来压缩/解压缩或者片段化/重新组装它们之间的消息。在这种物联网设备中，CoAP使得设备可以与网络主机之间安全通信，例如标准的电脑和智能电话等，它支持CoAPs协议。为了适应安全协议，例如在资源受限的物联网中的DTLS，把6LowPAN头压缩机制应用到这些协议中也是非常有益的。第四节里我们提出了DTLS的6LowPAN头压缩机制。以DTLS标准来设计这些报头压缩是非常重要的，要能够在传统的互联网上与现有的和新的DTLS主机之间互操作。四、DTLS压缩DTLS头压缩类似于IPHC，仅在6LowPAN网络中应用，如在传感器节点和6BR中使用。这是因为DTLS报头是UDP负载的一部分，而且路由所需的所有信息已经在IP层提取。在本章中除了描述DTLS的6LowPAN头压缩，我们详细介绍了如何以符合标准的方式将压缩的DTLS连接到6 LowPAN。A、 DTLS-6LowPAN为了将6LowPAN头压缩机制应用于压缩UDP负载中的头，我们要么需要在6LowPAN协议中修改当前UDP中的NHC编码 ，要么需要给UDP定义一个不同于ID位的新的NHC。第一个解决方案需在当前标准中修改，因此不是一个有利的解决方案。在这篇论文中我们用了第二种方案，它是6LowPAN标准的延伸，有一个类似的方法适合于区分NHC和GHC。UDP中NHC的ID位11110，与6LowPAN中定义的标准一样，表明UDP负载不压缩。定义ID位11011表明UDP负载用6LowPAN-NHC压缩。ID位1101目前在6LowPAN标准中还未定义。图4给出了我们提出的UDP中的NHC，它允许UDP负载的压缩。在我们的例子中，UDP负载包含用6LowPAN-NHC压缩的DTLS头。B、用于记录头和握手头的6LowPAN-NHC记录协议在使用DTLS的设备的生命周期中，给发送的每个数据包增加了13个字节长的头字段，另一方面，握手协议，在握手消息中增加了12字节的头。我们提出6LowPAN-NHC来压缩记录协议和握手协议，并分别把头长度减少到35个字节。在所有情况下，记录头仍是未加密的。因此，总是用在这章中解释的机制来压缩。为了向记录和握手头提供头压缩，我们考虑两种情况。在第一种情况中，记录头的片段（见第三部分）包含握手消息，我们用加密字节来压缩记录和握手头消息，并且给出了记录+握手中6LowPAN-NHC的定义。在第二种情况下，我们给记录头定义了6LowPAN-NHC（6LowPAN-NHC-R），与第一种情况不同的是，在记录头中的片段是应用数据而不是握手消息。我们成功实现了在DTLS握手后应用6LowPAN-NHC-R，并且对随后的消息进行加密和完整性保护。图2a给出了记录+握手头和记录头的6LowPAN-NHC加密。加密为有以下功能：前4位代表的ID字段用来区分 6LowPAN-NHC-RHS和其他编码，而且符合 6LowPAN-NHC编码方案。在 6LoWPAN-NHC-RHS情况下我们把ID位设置到了1000，在 6LoWPAN-NHC-R情况下ID位设置到了1001。版本（V）：如果是0，是最新的DTLS，版本1.2，省略了字段。如果是1，版本字段进行内联。时代（EC）：如果是0，使用了八位表示时代，最左边的八位省略。如果是1，所有16为进行内联。在大多数情况下实际年代要么是0要么是1。所以通常使用8位表示年代，这样允许更大的空间。序列号（SN）：序列号包含48位，有些事前导0。如果序列号设为0，就用了16位的序列号，并且左边的32位省略了。如果是1，所有的48位用于内联。如图5a所示，在 6LoWPAN-NHC-R情况下，我们的SN设为2位，这样可以更高效的压缩序列号字段。如果SN=00，就用了16位的序列号，并且左边的32位省略了。如果SN=01，就用了32位的序列号并且最左边的32位省略。如果SN=01，就用了32位的序列号，并且最左边的16位省略了。如果SN=10，就用了24位的序列号，并且最左边的24位省略了。如果SN=11，所有的48位序列号用于内联。片段（F）：如果F=0，则握手消息没有片段化，并且省略了fragment_offset 和 fragment_length字段。这是常见的情况，如果握手消息短于最大记录长度时就会发生。如果F=1，fragment_offset 和 fragment_length字段用于互联。在记录头上，content_ type字段总是用于内联。记录头中的长度字段总是省略，因为可以从较低层推算出：或者从 6LoWPAN的头，或者从 IEEE 802.15.4的头。我们必须从低层到高层解压layer-wise，直到完全解压出UDP报头。然后就可以知道UDP有效负载的长度并可以计算出DTLS负载长度。由于我们希望在受限的环境中每个UDP包只有一个DTLS记录头，所以记录头的长度字段也省略了。当 6LoWPAN中的源装置在每个UDP包中发送一个DTLS记录时，传统网络侧会有典型的目的装置在一个UDP包中传送多个DTLS记录头。然而，当6BR对传入的包执行压缩/解压时，有可能在6LoWPAN网络中给出这些包的路由之前，对每个UDP包执行一个DTLS记录。C、6LoWPAN-NHC for ClientHello我们提出了客户端友好型的消息6LoWPAN-NHC （6LoWPAN-NHC-C）。在握手过程中会发送两次客户端友好型消息，第一次没有cookie而第二次有服务器的cookie。图5b给出了用6LoWPAN-NHC对客户端友好型消息进行加密的过程。每一个压缩头字段的功能描述如下： 6LoWPAN-NHC-CH中前四位设为1010用来表示ID字段。会话ID（SI）：如果SI=0，session_id不可用，并将这一字段和8位的前缀长度字段省略。在DTLS协议中如果没有字段可用，或者用户想生成新的安全参数，那么session_id就是空的。只有在DTLS客户想要恢复旧会话时，才会使用ClientHello消息。真正的ClientHello中session_id字段包含0-32字节。然而，它的前缀中总是有一个8位的字段来表示session_id的大小。如果SI=1，session_id字段用于内联。Cookie（C）如果C=0，cookie字段不可用，省略这一字段和前缀8位。在ClientHello中真正的cookie字段包含1-255字节。然而，它总是有8位来表示cookie的长度。如果C=1，cookie字段用于内联。密码套件（CS): 如果CS=0，使用了CoAP默认的（强制性）支持自动的键管理的密码套件，并且这个字段和前缀16位被省略了。在当前的CoAP草稿中，TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8是一个强制性的密码套件。真正的密码套件字段包含2- 2161字节。并且在前缀中包含16字节来表示 cIPher_suites的大小。如果C=1， cipher_suites用于内线互联。压缩方法（CM）：如果CM=0，就为默认的压缩方法，例如， 用到了COMPRESSION_NULL，省略这个字段和前缀8位字段。实际上压缩方法字段包含1-28-1字节。它总是在前缀八位包含压缩方法的大小。如果CM=1，那么压缩方法字段用于内线互联。在ClientHello中随机字段总是用于内线互联并且总是省略版本字段。版本字段包含的值与DTLS记录头中的值一样。在TLS/SSL情况下，定义版本字段来让一个TLS的客户指定一个旧版本以兼容SSL客户机，而这在实际中很少用到。当前所有的Web浏览器在记录和ClientHello中使用相同的TLS版本。DTLS1.2（改编自TLS 1.2）提到客户在ClientHello消息中发送最新的支持版本。所有DTLS版本(1.0和1.2)的ClientHello消息相兼容。如果客户机不兼容这种版本，那么ServerHello消息将包含支持的版本。如果客户不能够处理服务器的版本，它将给出终止与协议版本连接的警报。使用 6LoWPAN-NHC-CH，通常只传送 ClientHello消息中的随机字段，而省略所有其他字段。同时，cookie会包含可压缩的字段。图6给出了一个包含ClientHello且未压缩的IP/UDP数据报。图7给出了我们提出的压缩DTLS，它包含ClientHello消息。在应用IPHC和 6LoWPAN-NHC头压缩后，数据报的尺寸是显著降低了。D、服务器友好型 6LoWPAN-NHC我们提出了SeverHello消息的 6LoWPAN-NHC（ 6LoWPAN-NHC-SH）。SeverHello与ClientHello除了密码套件和压缩方法字段分别位16和8位外，它们非常相似。图5给出了用 6LoWPAN-NHC 加密的ServerHello消息。每个压缩头的功能描述如下：前6 LoWPAN -NHC-SH中前四位设置为1011代表ID字段。版本（V）：为了在最初版本的握手中避免谈判，DTLS 1.2标准表明服务器的实现应该使用DTLS 1.0版本。如果V设为0，就使用DTLS1.0版本并省略版本字段。尽管DTLS1.2客户端不能假定服务器不支持更高的版本，否则它最终将使用DTLS1.0而非DTLS1.2。如果V设为1，那么版本字段用于内线互联。会话（ID），密码套件（CS）和压缩方法（CM）的加密方式与讨论的IV-C部分类似。为了不影响安全性ServerHello中的随机字段总是进行内联。E、其他握手消息中的 6LoWPAN-NHC剩下的强制性握手消息ServerHelloDone ClientKeyExchange，和Finish没有可以压缩的字段，因此所有字段进行内联。包含了证书链的可选的握手消息和包含了握手消息的数字签名的 CertificateVerify，也用来内线互联。然而，压缩一些证书中的字段也是可能的，但超出了本文的范围。 Pritikin提出了X.509的压缩计划。大多数时候不传送ServerKeyExchange消息，要么由于加密的出口限制要么因为服务器的证书消息包含足够的信息来承认客户端交换premaster secret。然而，如果传送了这一消息，那么所有的字段都用于内线互联。在可选的消息CertificateRequest的情况下所有的字段都可以省略。这是可能实现的，因为certificate_types，supported_signature_algorith和 certificate_authorities字段可以在6LoWPAN网络的一组支持的和优先的值之前定义，并且所有的网络中的节点使用相同的设置值。在传统的互联网中，在将消息发送到目的地之前，6 BR可以通过缺省设置值来填充空CertificateRequest消息。如果 6LoWPAN网络中没有定义缺省的设置值，那么所有字段用于内线互联。五、实现我们在Contiki中实现了Lithe，Contiki是物联网的开放源代码的操作系统。然而，我们建议的报头压缩机制可以在任何支持6LowPAN的操作系统中实现。Lithe的实现包含4个部分（1）DTLS（2）CoAP(3)CoAP和DTLS的集合模型。（4）DTLS头压缩。DTLS部分，我们使用了开放源代码的微型DTLS，它支持基于pre-shared键的基本的密码套件：TLS_PSK_WITH_AES_128_CCM_8。我们使得微型DTLS适用于WiSMote平台和支持 msp430-gcc的20位地址。（版本4.7.0）。CoAP部分，我们在Contiki操作系统中实现缺省的CoAP。我们开发出了连接CoAP和DTLS的集成模型，并可以使用CoAPs协议。这种集成允许应用程序独立访问CoAPs，在这里CoAP消息都是透明的传送给能够传输保护信息到目的地DTLS。所有的传入消息都通过DTLS来保护，因此在DTLS层首先处理并透明传送给驻留在应用层的CoAP。第四节 我们实现提出的头压缩作为在Contiki操作系统中实现的6LoWPAN 的扩展。6LoWPAN 层在IP层和MAC层之间。IP层的数据包可以从节点传出来作为输出数据包。MAC层节点接受到的数据包被看做输入包。6LoWPAN层从两个方向处理所有UDP包。因此，我们使用两种方法来从其他UDP包中区分携带DTLS消息的UDP包做为有效载荷。在输入包情况下，预配置的默认DTLS端口用于识别CoAPs消息。在第二种情况下，包从MAC层接受，NHC-for-UDP和DTLS头的NHC中的DTLS端口和ID位用来区分压缩头和未压缩的头。第四节中给出了细节。此外，重要的是要强调，尽管应用头压缩，端到端的安全性是不能降低的。这是由于DTLS的设计和我们的努力来保持标准兼容。头字段在与密码套件联系之后，在记录层进行完整性保护。在压缩/解压过程中不修改原来的标题也保护了完整性。在6LoWPAN层解压后，在DTLS层进行包的完整性检查。把正确性完整性保护作为正确的减压证明。六、评价我们在运行Contiki操作系统的真正的传感器节点上评估Lithe。我们用 WiSMote作为硬件平台。该平台的配置有（1）16兆赫，MSP430 5系列、16位RISC微控制器，（2）128/16 kB的 ROM/RAM，（3）一个IEEE 802.15.4 (CC2520)收发器。我们选择WiSMotes是因为由于RAM和ROM的需要DTLS实现，这会在第六章B部分详细讨论。网络设备包括两个直接通过无线电通信的WiSMotes。CC2520收发器提供了一个AES- 128安全模块。然而，对我们不使用AES硬件支持而依靠软件AES来评估。利用涉及DTLS的AES硬件支持的加密计算得到了更高的性能。我们的评价关注的是DTLS报头压缩对响应时间和能源消耗节点的影响。因此，由于软件AES造成的性能损失不会影响我们的评估。此外，为了能够分析单独压缩的处理开销，我们不支持链路层安全。在先前的工作中，我们已经用AES支持的硬件来评估性能增益。在那里，我们实施和评估了IEEE802.15.4链路层安全。A、 减少数据包大小我们可以使用6LoWPAN-NHC压缩机制显著降低DTLS头的长度。表1显示了我们提出的DTLS头压缩显著减少了头比特的数量，这也类似地减少了无线传输时间。包含在所有DTLS消息中的记录头，可以压缩64位，节省62%的空间。在握手头的情况下，可以节省75%的空间。应用程序数据构成的最大数量的DTLS消息。把记录头从104位减少到40位，就允许在每个包中多传送64位。大于链路层MTU的数据包是分散的。碎片不仅引入更多的节点和网络开销，它也带来安全漏洞。因此，只要有可能，最好避免碎片。在有效载荷略高于分割阈值时，我们使用压缩来避免碎片或减少碎片的数量。此外，在有限的网络中减少传输比特对网络的性能和寿命有着巨大的影响。无线电通信的能源消耗通常高于节点内计算约10倍。压缩的能源消耗平衡在用于压缩和解压缩的额外内部节点与减少无线传输之间。这种权衡的影响将在第六章C部分进一步讨论。B、RAM和ROM的要求我们用MSP430工具链中的msp430-objdump工具来分析静态RAM和ROM。如表2所示，Lithe需要59.4kB的ROM和9.2kB的RAM。DTLS的实现包括密码功能并且DTLS状态机需要16.8 kB的ROM和3.7 kB的 RAM。这使得DTLS对ROM来说是仅次于操作系统的主要贡献者。 The CoAP-Server 需要8 kB的ROM 和.5 kB 的RAM. 我们的CoAP-Server提供单个的资源，这基于CoAP GET请求，把可变负载长度的响应消息发送回来。我们的评价中用这个来分析压缩对不同负载长度的CoAPs消息的影响。COAP得以实现的脚本取决于提供的资源。DTLS头实现了对ROM压缩2820字节，对静态RAB压缩一个字节。一个字节的静态RAM对UDP报头的压缩。在Contiki中 6LoWPAN使用的用来压缩和片段化的（没有DTLS压缩）全部ROM是3782字节。这验证了压缩的DTLS使用相同的ROM顺序作为标准的6LoWPAN。如今的感知节点，例如带有128K字节的WiSMote一定能满足压缩的CoAPs和其他操作系统的组件，而且还可以提供为其他应用提供重要的空间。C、运行时间性能我观察当使用压缩的DTLS时的运行时间性能，并把它与使用为经压缩的DTLS做比较。我们分别在一个具有 Radio Duty Cycling (RDC)和没有RDC的6LoW-PAN网络中进行这个实验。当使用RDC时，收音机在大部分时间是关闭的，并且要么在特定的间隔打开来检查传入数据包的媒介，要么在传送包是打开。我们使用在Contiki操作系统中提供的duty cycled MAC协议，有着默认设置的X-MAC。在我们对运行时间进行评估时，我们关注的是传感器节点的能量消耗和网络范围的执行时间。为评估能量消耗，我们使用Contiki操作系统提供的能量估计模块。这个模块提供CPU的使用时间，LPM，特定函数收发器。每个这些组件的绝对计时器值可以使用以下方程转换成能源：（1） DTLS压缩开销：DTLS头的节点内计算压缩和解压缩而引起的开销几乎可以忽略不计。然而，为了完整性我们测量和显示它的完整性。图8显示了头消息中用于压缩（压缩和解压缩）的额外能量消耗。每一个握手消息包含记录和握手头。平均来说，每个基于预共享秘钥的DTLS握手消息消耗4.2uJ能量。（2） CoAPs初始化：在CoAPs初始化过程中在使用DTLS握手协议的两个通信终端建立了一个安全会话。这一握手过程同时使用了记录和握手头，这意味着这两种头都可以被压缩。额外的节点内计算和减少数据包大小之间的权衡表明他自身在DTLS握手时传输包的能源消耗。表3把在应用压缩情况下的传输能量损耗和未应用压缩情况下的能量损耗进行了比较。平均来看，传输和接受压缩包需要使用的能量减少15%。这是因为在压缩过程中包的大小变的更小。（3）CoAPs请求-响应：一旦CoAPs初始化过程完成了，例如已经完成了握手，一个感知节点就可以通过DTLS记录协议来发送/接收安全的CoAP消息。尽管与记录协议相比握手协议的能量消耗更大，但它旨在初始化阶段或接下来的预握手阶段执行。为了测量记录头的压缩性能，我们在CoAP请求-应答消息过程中测量能量消耗和往返时间（RTT）。当客户准备CoAP请求时我们开始测量，并在收到服务器应答和处理后结束。相应的CoAP响应包含不同的负载长度。更精确来说，在0-48字节范围中使用了8种不同的负载大小。我们选择了48是因为在CoAPs情况下，48字节的CoAP负载 中6LoWPAN 片段发挥了作用。然而，Lithe不会导致碎片，因为通过压缩减少了比特。可以在图9a中看出这种作用，该图表明了CoAP的客户端，以及传送压缩和未压缩的CoAPs的请求和应答（不带RDC且长度不一样）的客户机的平均内部节点损耗。由于应答消息总是一个常量，所以传送CoAP GET应答消息所需的能量一样。因此，CoAP应答的能量消耗可以通过压缩来降低10%。因此，减少的能量范围在4-26%，其中最大可以节省48字节的能量。为了分析CoAPs请求响应的总体能量损耗，我们叠加了客户端和服务器之间的能量损耗，并在图9b中给出了描述。在该图中我们观察到平均节省了约7%的能量。然而，通过压缩来避免碎片的情况下，节省的能量达到了20.6%。这是因在48字节的负载中，6LoWPAN在两个碎片中传送包，而经过压缩后包就不会在碎片中传送。减少的传送时间也会影响将RTT应用于CoAPs的请求应答消息，如图10b所示，在没有RDC的情况下，RTT平均减小1.5%，除了48字节的负载。在这种情况下，带压缩的RTT甚至能效77%，因为避免了碎片。为了评估由安全性引起的总体开销，我们也在没有安全性的CoAP中加了值。只要不需要碎片。没有安全性的CoAP中的RTT占CoAPs的1/3。在图10b中我们看有RDC的RTT，我们可以看到所有的三种情况：（1）没有任何安全性的CoAP（2）CoAPs（3）带有DTLS压缩的DTLS（Lithe），RTT值都在同一范围，处理CoAP应答消息有48字节的负载。这是RDC的副作用。RDC通过把收音机加入大部分休眠状态而节省了很多能量。然而这样的代价是时延变大。RDC中的包并不直接传输。发送方必须等到接收方醒来，最坏的情况会将等待整个休眠期。结果表明，总体来说使用RTT的等待时间比未使用RTT长。我们在带有RDC的网络中观察到了这一现象。例如，图10b，带偶48字节的负载，压缩使得RTT缩小了50%。七、结论能够应用COAP的主机将会成为物联网不可分割的一部分。此外，现实中使用COAP的装置需要安全解决方案。为此，DTLS是使CoAP(CoAPs)安全的标准协议。在这篇论文中我们调查了通过 6LoWPAN头压缩来减少DTLS开销的可能性，并且给出了6LoWPAN第一个DTLS报头压缩规范 。结果定量的表明可以压缩DTLS并且可以使用6LoWPAN标准压缩机制来大大减少它的开销。我们对压缩的DTLS的实现结果和评估表明，与CoAPs相比，由于从能量消耗和网络响应时间方面来看，DTLS压缩具有高效性，这使得可以减少CoAP的开销。如果使用未压缩的DTLS导致了6LoWPAN的碎片，那么压缩的DTLS与未压缩的DTLS有着显著的不同。在未来的工作中我们计划在有真实的应用场景的真实的物联网系统中部署Lithe。这样的物联网设置由受限设备，标准的电脑和智能手机组成。在现实世界中部署帮助我们对一个异构物联网进行彻底评估，并最终证明Lithe在对安全敏感的应用中的使用情况。15