雷竞技网页版研究与评论-国际期刊雷竞技苹果下载

国际计算机与通信工程创新研究杂志

菜单

在线刊号(2320-9801)印刷刊号(2320-9798)

所有提交的EM系统将被重定向到网上投稿系统．作者被要求将文章直接提交给网上投稿系统各自的日志。

使用增强的DTLS实现物联网的CoAP安全

特A.Chavan1米纳特·k·尼格特2
  1. 墨西哥墨西哥城国际医学科学院"La Raza"国家医疗中心肾脏科
  2. 墨西哥墨西哥城国际医学研究所"La Raza"国家医疗中心传染病科
有关文章载于Pubmed，谷歌学者

更多相关文章请访问国际计算机与通信工程创新研究杂志

国际计算机与通信工程创新研究杂志

摘要

物联网(IoT)是下一代技术，旨在通过一起操作智能传感器和智能物体来改善和优化日常生活。在应用层，资源受限设备之间的通信希望使用CoAP (constrained application protocol)协议。通信安全是物联网环境的一个重要方面。然而，闭源安全解决方案并不能帮助制定物联网中的安全性，从而使设备能够安全地相互通信。为了保护机密信息的安全传输，CoAP使用DTLS (datagram transport layer security)作为通信设备之间通信和认证的安全协议。DTLS最初是为通过可靠和高带宽链路连接的强大设备而设计的。本文提出了DTLS和CoAP在物联网领域的协作。另外提出了DTLS报头压缩方案，通过符合6LoWPAN标准，有助于减少数据包大小、能源消耗和避免碎片。此外，本文提出的DTLS报头压缩方案不影响DTLS提供的点对点安全性。由于DTLS已被选择作为CoAP下面的安全协议，因此还通过在DTLS中引入原始公钥来增强现有DTLS。

关键字
CoAP, DTLS，通用头压缩，下一个头压缩。

介绍
连接ip的智能设备正在成为互联网的一部分，从而形成了物联网(IoT)。由于其拥塞控制算法，TCP在无线网络中的性能很低，而且它不能很好地与传感器网络中的低功率无线电和有损耗链路一起工作。因此，无连接的UDP在物联网中应用较多。此外，主要设计用于在TCP上运行的HTTP在有损耗和受限的环境中效率很低。CoAP的设计是为了满足特定的需求，例如在资源受限的环境中简单、低开销和多播支持。对于连接到不受信任的互联网的物联网设备来说，安全性尤其重要。压缩IPsec可以保证6LoWPAN网络中的节点与Internet[4]中的主机之间的通信安全。定义了Next Header Compression (NHC)编码来压缩Authentication Header (AH)和Encapsulating Security Payload (ESP)扩展头。
Jorge等人[5]扩展了我们的解决方案，并在隧道模式中包括IPsec。他们在TinyOS中实施和评估他们的提案。在特定机器上运行的所有应用程序之间共享IPsec安全服务。尽管我们的6LoWPAN压缩IPsec可以用于在网络层提供轻量级的端到端安全，但它主要不是为HTTP或CoAP等web协议设计的。对于web协议，TLS或DTLS是常见的安全解决方案。TLS工作在TCP之上，而在6LoWPAN网络中UDP是首选。Brachmann等人[6]提出TLS-DTLS映射来保护物联网。但是，这需要在6BR上存在可信的6BR和端到端安全漏洞。Kothmayr等人[7]研究了DTLS在带有可信平台模块(TPM)的6lowpan中的使用，以获得对RSA算法的硬件支持。然而，他们已经使用了DTLS，没有使用任何压缩方法，这将缩短整个网络的生命周期，因为DTLS消息中的冗余位。 Granjal et al. [8] evaluate the use of DTLS as it is with CoAP for secure communication. They note that payload space scarcity would be problematic with applications that require larger payloads. As an alternative, they suggest to employ security at other layers such as compressed form of IPsec. In a recent work, Keoh et al. [9] have discussed the implications of securing the IP-connected IoT with DTLS and propose an architecture for secure network access and management of unicast and multicast keys with extended DTLS.
CoAP提议使用DTLS作为自动密钥管理、数据加密和完整性保护以及身份验证[1]的安全协议。支持DTLS的CoAP被称为安全CoAP (CoAP)。DTLS是一种聊天协议，需要大量的消息交换来建立一个安全会话。DTLS最初是为消息长度不是关键设计标准的网络场景而设计的。因此，对于受限的物联网设备，使用DTLS协议效率很低。为了匹配基于IEEE 802.15.4网络的有限资源和大小限制，定义了6LoWPAN报头压缩机制。6LoWPAN标准已经为IP报头、IP扩展报头和UDP报头定义了报头压缩格式。应用6LoWPAN报头压缩机制来压缩DTLS报头尤其有益。在本文中，我们通过使用6LoWPAN报头压缩机制来压缩DTLS协议，从而提供了一个安全的CoAP。这种机制有两个目的:首先，由于通信比计算需要更多的能量，因此它通过减少消息大小来实现能源效率。 Second, avoiding 6LoWPAN fragmentation that is applied when the size of a datagram is larger than the link layer MTU. Avoiding fragmentation, whenever possible, is also important from the security point of view as the 6LoWPAN protocol is vulnerable to fragmentation attacks [4].

背景
在本节中，我们将重点介绍安全coap (IoT的HTTPs变体)开发中涉及的协议和技术。

CoAP
CoAP是一种web协议，运行在不可靠的UDP协议上，主要是为物联网设计的。CoAP是最常用的同步web协议HTTP的变体，专为受限设备和机器-机器通信而定制。然而，尽管CoAP提供了一个类似于HTTP的REST接口，但它的重点是比当今Internet的其他变体更轻量级和更经济。为了保护CoAP传输，数据报TLS (DTLS)被提出作为主要安全协议[2]。类似于TLS保护的HTTP (HTTPs)， dtls安全的CoAP协议被称为CoAP。在CoAP中，与HTTP一样，通用资源标识符(URI)用于访问给定主机上的资源。CoAP是一种相对简单的请求和响应协议，提供可靠和不可靠的通信形式。对于CoAP协议，将使用“CoAP”URI方案。物联网设备上的web资源可以通过CoAPs协议安全地访问:
/ MyResource coaps: / / myIPv6Address:港口
启用coap的设备可能扮演客户端角色、服务器角色或两者都扮演，或者发送不符合要求的消息而没有响应。为受约束的IP网络定义新协议，而不是简单地重用HTTP的原因是大大降低实现复杂性(代码大小)的开销，并降低带宽要求。这种数据减少还有助于提高可靠性(通过减少链路层碎片)，并减少典型低功耗损耗无线网络(如IEEE 802.15.4)的延迟。

迪泰
DTLS可以说是最适合提供通道安全性的单一安全协议，主要是因为它是一个相当完整的安全协议，可以执行身份验证、密钥交换，并使用协商好的密钥材料和算法保护应用程序数据。使用DTLS作为物联网的唯一安全套件，可以实现以下安全保护。
•网络访问:dtls作为一种身份验证协议，可以使用PSK模式、原始公钥或公钥证书对加入网络的新设备进行身份验证。成功的DTLS握手的结果在新设备和授权实体(例如，6LBR)之间创建了一个安全通道。该安全通道使授权实体能够根据网络所有者配置的规则安全地将L2密钥分发到连接设备。如果新设备和授权实体在MAC层是单跳的，则DTLS握手消息不会被MAC层丢弃。但是，如果新的设备和授权实体在MAC层是多跳的，DTLS消息将在MAC层被丢弃，因为它们还没有受到L2密钥的保护。
•安全通信通道:一个DTLS端到端会话可以在两个通信设备之间建立，一个在6LoWPAN内部，另一个在外部，以安全传输应用程序数据(CoAP消息)。
应用程序数据由DTLS记录层保护，即使用新的惟一会话密钥进行身份验证和加密。DTLS由两层组成:下层为Record协议，上层为Handshake、Alert、ChangeCipherSpec三种协议中的一种或应用程序数据。Record协议是上层协议的载体。Record头包含其他内容类型和片段字段。根据内容类型中的值，fragment字段包含握手协议、警报协议、ChangeCipherSpec协议或应用程序数据。Record头主要负责在握手过程完成后以密码方式保护上层协议或应用程序数据。记录协议保护包括保密性、完整性保护和真实性。握手协议是一个复杂的聊天过程，以异步方式包含大量消息交换。握手消息通常在飞行中组织，用于协商安全密钥、密码套件和压缩方法。完整的握手过程如图1所示。
•密钥管理:由于DTLS具有更新会话密钥的能力，这种机制可以用于支持6LoWPAN网络中的密钥管理。在网络访问阶段，6LBR分发L2密钥作为网络访问认证过程的一部分。因此，可以重用相同的通道来促进密钥管理，从而使L2密钥在必要时由6LBR更新。

6 lowpan
6LoWPAN标准定义了IPv6连接的wsn(也称为6LoWPAN网络)中IPv6数据报的报头压缩和分片机制。压缩机制包括IP头压缩(IPHC)和下一个头压缩(NHC)。IPHC编码可以将IPv6头长度压缩为单跳2字节，多跳7字节(1字节的IPHC, 1字节的dispatch, 1字节的hop Limit, 2字节的Source Address和2字节的Destination Address)。在IPHC中的其他编码位中有NH位，当设置它时，表示下一个报头使用NHC压缩。NHC用于对IPv6扩展头和UDP头进行编码。NHC编码的大小是字节的倍数(大多数是一个字节)，其中包含可变长度的ID位和特定头部的编码位。因此，值得扩展6LoWPAN报头压缩机制来压缩这些协议报头。6LoWPAN标准定义的NHC编码可用于将报头压缩到UDP，但不能压缩到上层。需要一个新的NHC，因为在UDP的NHC中没有NH位，这表明UDP有效负载也被压缩了。在第四节中，我们提供了6LoWPANDTLS集成和6LoWPAN NHCs来压缩DTLS。

系统概述
我们的压缩DTLS在6LoWPAN网络中启用Lithe的主机和使用未压缩coap的典型Internet主机之间维护真正的端到端(E2E)安全性。图2显示了一个典型的物联网设置，其中由启用coap的节点组成的6LoWPAN网络通过6LoWPAN边界路由器(6BR)与Internet连接。如图2所示，报头压缩仅应用于6LoWPAN网络内，即约束节点和6LoWPAN边界路由器(6BR)之间。6BR在6LoWPAN网络和Internet之间使用，用于在两个领域之间转发之前对消息进行压缩/解压缩或/和分段/重组。在这个物联网设置中，启用CoAPs的设备可以安全地与支持CoAPs协议的标准计算机、智能手机等互联网主机通信。为了使诸如DTLS之类的安全协议适用于资源受限的物联网设备，对这些协议应用6LoWPAN报头压缩机制也是有益的。

迪泰压缩
在本节中，除了描述DTLS的6LoWPAN报头压缩外，我们还详细介绍了如何以兼容的方式将压缩后的DTLS链接到6LoWPAN。

DTLS-6LoWPAN集成
本文提出的方案是对6LoWPAN标准的扩展;类似的方法适用于区分NHC和GHC。在6LoWPAN标准中定义的UDP NHC中的ID位11110表示UDP有效负载没有被压缩。我们定义ID位11011来指示UDP有效负载是用6LoWPAN-NHC压缩的。ID位11011目前在6LoWPAN标准中未分配。图3显示了我们提出的允许UDP有效负载压缩的UDP NHC;在我们的例子中，UDP有效载荷包含6LoWPAN-NHC压缩的DTLS报头。

6LoWPAN-NHC用于记录和握手头
记录协议在使用DTLS的设备的整个生命周期中为每个发送的数据包添加13个字节长的报头字段。另一方面，握手协议为握手消息增加了12字节的消息头。我们建议使用6LoWPANNHC来压缩Record和Handshake报头，并将报头长度分别减少到5和3个字节。在第一种情况下，Record报头片段字段包含一个握手消息，我们使用单个编码字节压缩Record报头和握手报头，并为Record+ handshake定义6LoWPAN-NHC-RHS。在第二种情况下，我们为记录报头定义6LoWPAN-NHC (6LoWPAN-NHC- r)，其中记录报头中的片段字段是应用程序数据而不是握手消息。图4显示了Record+Handshake头和Record头的6LoWPANNHC编码。编码后的位有以下作用:前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，则使用8位epoch，并且省略最左边的8位。如果是1，则epoch的所有16位都内联携带。
在大多数情况下，实际的epoch不是0就是1。因此，大多数时间使用8位epoch，允许更高的空间。
序列号(SN):序列号由48位组成，其中一些是前导零。当“SN”设置为0时，表示使用16位的序列号，省略最左边的32位。如果是1，则序列号的所有48位都内联进位。以6LoWPAN-NHC-R为例，如图4所示，我们使用两位表示SN，可以更有效地压缩序列号字段。这里如果SN设置为00，则使用16位的序列号，最左边的32位被省略。如果是01，则使用32位的序列号，最左边的16位被省略。如果是10，则使用一个24位的序列号，最左边的24位被省略。如果是11，则序列号的所有48位都内联进位。
片段(F):如果为0，则握手消息不分段，并且省略分段偏移量和分段长度字段。这是常见的情况，当握手消息不大于最大记录大小时就会发生这种情况。如果是1，则字段片段偏移量和片段长度内联携带。

6LoWPAN-NHC为客户，你好
在握手过程中，发送两次ClientHello消息，第一次没有cookie，第二次有服务器的cookie。图5显示了ClientHello消息的6LoWPAN-NHC编码。
6LoWPAN-NHC-CH的前四位表示ID字段，设置为1010。
会话ID (SI):如果为0，表示会话id不可用，该字段和前缀长度字段中的8位将被省略。在(D)TLS协议中，如果没有会话可用，或者如果客户端希望生成新的安全参数，会话id为空。只有当DTLS客户端想要恢复旧会话时，ClientHello消息才使用会话id。ClientHello中实际的session id字段长度为0 ~ 32个字节。但是，它总是以一个包含会话id大小的8位字段作为前缀。如果SI设置为1，则会话id字段内联。
饼干(C):如果为0，则cookie字段不可用，该字段及其前缀的8位长度字段将被省略。ClientHello中实际的cookie字段长度为0 ~ 255字节。但是，它总是有一个8位长的字段，包含cookie的大小。如果C设置为1，则将cookie字段带入一行。
密码套件(CS):如果为0，则使用支持自动密钥管理的CoAP的默认(强制)密码套件，该字段和带前缀的16位长度字段将被省略。在当前的CoAP草案中，TLS-ECDHE-ECDSAWITH- AES-128-CCM-8是一个强制的加密套件。实际的密码套件字段包含2到216-1个字节，并且总是以一个包含密码套件大小的16位字段作为前缀。如果CS设置为1,cipher suites字段将内联携带。
压缩方法:如果为0，则使用默认的压缩方法，即compression NULL，并且省略该字段和带前缀的8位长度字段。实际压缩方法字段长度为1 ~ 28-1字节。它总是以一个包含压缩方法大小的8位字段作为前缀。如果CM设置为1，压缩方法字段将内联传输。
图6显示了一个未压缩的IP/UDP数据报，其中包含一个ClientHello。一个6LoWPAN压缩的IP/UDP数据报，使用我们建议的压缩DTLS，包含ClientHello消息，如图7所示。应用IPHC和6LoWPAN-NHC报头压缩后，数据报大小显著减小。

6LoWPAN-NHC for ServerHello
ServerHello与ClientHello非常相似，只是密码套件和压缩方法字段的长度分别固定为16位和8位。图5c显示了ServerHello消息的6LoWPAN-NHC编码。每个压缩报头字段的作用说明如下:6LoWPANNHCSH中的前四位表示ID字段设置为1011。
版本(V):为了避免在初始握手时进行版本协商，DTLS 1.2标准建议服务器实现应该使用DTLS 1.0版本。当V为0时，版本为DTLS 1.0, version字段省略。但是，DTLS 1.2客户端不能假定服务器不支持更高的版本，否则它最终将协商DTLS 1.0而不是DTLS 1.2。如果V被设置为1，版本字段将内联携带。
会话ID (SI)、密码套件(CS)和压缩方法(CM)的编码方式与上面讨论的类似。为了不影响安全性，ServerHello中的随机场总是内联携带的。

6LoWPAN-NHC用于其他握手消息
其余的强制握手消息ServerHelloDone、ClientKeyExchange和Finish没有可以压缩的字段，因此所有字段都内联携带。包含证书链的可选握手消息Certificate和包含握手消息的数字签名的Certificate Verify也内联携带。

增强
除了提出的系统之外，我们还添加了新功能，通过使用原始公钥来改进端到端身份验证。DTLS中的PSK操作模式只支持物联网设备之间的部分互操作性，因为设备制造商需要彼此预先共享一些密钥材料，以便允许他们的设备彼此安全地通信。在多供应商环境中建立这样的信任可能很困难。另一端是基于x .509的公钥基础设施(PKIX)，使物联网设备能够相互验证。在DTLS中使用原始公钥已经标准化，以减轻物联网设备在执行DTLS握手协议时存储和传输X.509证书的负担。这允许设备预先配置(在制造期间)设备需要与之通信的专用服务器的公钥，以及设备本身的公钥。
当设备使用原始公钥执行DTLS握手协议时，必须使用新定义的客户端证书类型和服务器证书类型的TLS扩展。原始公钥封装在只包含原始密钥和算法标识符的SubjectPublicKeyInfo结构中。物联网设备作为DTLS客户端发起DTLS握手协议，表示其在发送带有RawPublicKey扩展名的ClientHello消息时能够处理原始公钥。服务器完成客户端请求，通过服务器证书类型有效负载中的RawPublicKey值表示，并将原始公钥提供给客户端到certificate有效负载中。如果需要客户端身份验证，服务器可以向客户端发送CertificateRequest消息，要求客户端发送其原始公钥进行身份验证。预先配置了原始公钥的客户端将其在证书有效负载中返回给服务器。

结论及未来工作
安全CoAP是现实物联网环境中资源受限设备的基本需求。DTLS是启用安全CoAP (CoAP)的标准协议。该系统提出了通过6LoWPAN报头压缩降低DTLS开销的可能性，并提出了首个6LoWPAN的DTLS报头压缩机制。压缩DTLS用于CoAPs在节点能耗、内存需求和网络响应方面是有效的。作为未来的工作，该系统可以部署在现实世界的物联网环境中，包括智能传感器、受限设备和智能手机等，并实现实时应用。这样的部署有助于深入研究和评估该保密应用系统的意义。

数字一览
图1 图2 图3 图4
图1 图2 图3 图4
图5 图6 图7 图8
图5 图6 图7 图8

参考文献









全球科技峰会