实验目的及要求
CoAP协议是物联网应用中重要的应用层协议,上一次实验开展了CoAP协议的分析,对CoAP协议的交互机制进行了分析。但如果CoAP协议不进行安全实现,黑客可以恶意发布信息给服务器,特别是在工业、交通等物联网应用场合后果不堪设想。本实验旨构建CoAP协议安全通信。
实验要求
- 掌握CoAP的安全通信的基本原理;
- 设计CoAP安全通信的安全措施;
- 实现基于DTLS的CoAP通信。
实验基本步骤
Step1:CoAP安全通信的基本原理
Step2:设计CoAP安全通信的安全措施
Step3:实现基于DTLS的CoAP通信
实验过程、分析及有关程序代码
1 CoAP安全通信的基本原理
1.1 简单介绍
根据CoAP协议所遭受的安全威胁,CoAP协议标准规定需要依靠DTLS协议来提供相关安全保障,并为CoAP协议定义了三种安全模式,DTLS协议与CoAP协议的关系如图1.1所示。
CoAP协议标准RFC7252中对协议的安全模式描述如下:
- NoSec模式:没有安全性(DTLS协议被禁用),即应用层和传输层并没有加入安全机制,此时可以采用其他的安全技术保障其安全性;
- Pre Shared Key模式:(DTLS协议启用),在通信双方预存储一个预共享密钥的列表,其中每个密钥都对应着一个相应的标识;
- Raw Public Key模式:(DTLS协议启用),通信双方拥有公私钥对,但是没有X.509证书。通信双方使用公钥类型字段作为证书的载荷,从而降低构造证书签名所带来的开销;
- Certificate X.509模式:(DTLS协议启用),通信双方拥有公私钥对,并且引入第三方信任中心(CA)构造X.509证书,将构造的证书发送到它的请求方,通信双方通过验证证书来完成认证。
2 设计CoAP安全通信的安全措施
2.1 概述
DTLS的目标应用主要是C/S及其变体。这也是TLS的设计目标并且已很好工作。展示的安全模型中,server通过DNS名称和IP地址被认证,Client是匿名的或者被其他形式认证,典型的是在应用层通过用户名/密码来处理。
这个实现并不真正安全。然而,应用程序的设计者们,向在添加安全性的时候尽量能够维护他们的协议和实现架构。这个实现制造了一个类似于TLS或IPSec的有吸引力的信道安全协议,因为改动之非常小。从这个观点看来,理想的数据报信道安全协议应该取代对Server的DNS和基于IP认证的强加密认证,而是把client认证留给应用层协议。
2.2 握手协议
Handshake协议最主要的作用就是完成通信双方的认证过程,DTLS协议的Handshake协议相比TLS协议增加了Cookie机制和消息重传的功能。Handshake协议采用了Cookie交换机制,在客户端发送的第一条报文Client Hello中Cookie值为空。资源服务器接收到第一条请求报文后,会生成一个Cookie值填充至响应报文Hello_ Verify Request中。客户端接收到响应报文后,提取此Cookie值,再次发送至资源服务器。资源服务器接收后与自身的Cookie值进对比,如果对比结果相同,オ可以进行下一步通信,其交换过程如图2.1所示。
在完成了Cookie校验机制后,DTLS协议开始端到端的握手过程,其完整的握手过程如图2.2所示。
DTLS协议完整的握手交互过程解释如下:
- Client_Hello:报文中含有Cookie的值,此时Cookie值为空;
- Hello_Verify_Request:客户端检验接收到的Client_Hello报文中Cookie值是否为空,如果为空则说明之前并未建立过连接,服务器会生成一个Cookie值返回至客户端中;
- Client_Hello:此时客户端接收服务器发来的报文,提取出Cookie值填入此次报文中;
- Server_Hello:服务器接收客户端报文后,提取Cookie值与自身的值进行验证,验证通过则继续握手连接;
- Server Certificate:此报文段包含一个证书字段,用来验证服务器的身份(如果使用对称密钥算法则此条报文忽略);
- Server Key Exchange:此过程为密钥交换的过程,即采用上一段报文中所选择的密钥协商算法进行通信双方的密钥协商;
- Certificate Request:如果通信双方采用的是基于证书的认证模式,此条报文要求客户端要回应一个自身构造的证书,双方通过基于证书的认证签名机制来完成认证的过程(如果使用对称密钥算法,则此条报文忽略);
- Server Hello Done:此条表示服务器端操作完成,将上述三条报文打包发送至客户端,等待客户端;
- Client Certificates:客户端接收到上述报文后,如果双方使用了证书模式,则按照要求进行证书的验证以及签名等操作(如果使用对称密钥算法,则此条报文忽略);
- Client Key Exchange:如果客户端与资源服务器采用的是对称密钥算法,则此条报文用来协商生成会话密钥;
- Certificate Verif:此条报文对服务器端构造的证书进行解签名验证(如果使用对称密钥算法,则此条报文忽略);
- Change Cipher Spec:此消息用来告知资源服务器端所生成的会话密钥或者告知资源服务器双方的认证已经完成;
- Client Finished:此条报文表示客户端的操作已经完成,将上述三条报文打包发送至资源服务器;
- Change Cipher Spec Server:此消息用来完成会话密钥的生成或者证书的验证;
- Server Finished:此消息表示资源服务器端的操作已经全部完成,双方可以通过协商的会话密钥或者公私钥进行消息的加密。
3.实现基于DTLS的CoAP通信
3.1 简单实现
首先,我在kali中打开一个终端,使用下面的命令克隆FreeCoAP的源码,然后安装相关的依赖包和工具autoconf、libtool-bin、libgnutls-dev和wireshark-qt,如图3.1所示。
详细安装步骤可以参考下面的文章
https://github.com/keith-cullen/FreeCoAP
然后,在kali中打开另一个终端,通过调用tcpdump捕获通信数据包,如图3.2所示。
接着,再打开一个新的终端运行Demo的服务器,如图3.3所示。
最后,打开最后一个终端,运行Demo的客户端,如图3.4所示。
3.2 用wireshark分析
首先,用wireshark打开在3.1中用tcpdump捕获的通信数据包,发现了DTLSv1.2协议和信息通信的过程,如图3.5所示。
然后,在预共享密钥模式下,在应用层和UDP之间引入DTLS协议,将预共享密钥机制与DTLS协议中密码规则协议相结合,采用TLS_ECDHE_ECDSA_WITH_AES_128_GSM_SHA256算法,实现可信的端到端安全关联和数据的加密,如图3.6所示。
接着,在密钥交换的过程中,利用Diffie-Hellman密钥交换协议巧妙确定对称密钥,达到安全通信的目的。另外,该过程还利用ecdsa_secp256r1_sha256算法对通信的数据进行签名,获得长度为71的签名,如图3.7所示。
密码规则协议中使用PSK预共享机制有以下两个原因:
- 在网络资源受限的环境下,使用PSK预共享密钥算法相比公私钥等模式造成的开销较低;
- 预共享密钥机制相比其他密码学算法的配置过程更加简洁,比如在一个封闭的网络环境中,大多数操作都是预先手动配置的,而配置PSK预共享密钥相比RSA公钥证书模式要更方便。
下一步,就是证书的验证过程,就是利用相同的签名算法进行验证,得到与上一过程相同的签名,如图3.8所示。
改变密码规则协议此协议是起到一个标志的作用,用来告知客户端和资源服务器已经完成了密钥的交换等过程,如图3.9所示。
警告协议Alert协议是一种返回机制,即通信双方在交互的时候如果发生错误或者安全威胁,就会通知通信双方,通信双方会结束会话避免信息的泄露,如图3.10所示。
最后,在上面过程的基础上,服务器和客户端就可以传输加密的握手包信息和加密数据了,如图3.11所示。
3.3 代码展示
服务器:
1 | #include <string.h> |
客户端:
1 | #include <string.h> |
实验体会
在这次实验中,我和同学遇到了极大的困难,对我来说,这次实验堪称大学以来最难做的实验,但是,通过我和舍友一起翻阅资料,还是能够按时完成实验。
通过这次实验,我又一步加深了对C语言的理解,使用C语言实现CoAP服务器和客户端的加密通信。同时,查阅了RFC7252中对CoAP的安全模式,理解了DTLS协议和CoAP协议在计算机网络中的层次,深入分析CoAP协议的基本原理,明白了客户端和服务器之间利用预共享密钥机制之间的密钥协商过程。另外,通过在kali中使用tcpdump捕获通信数据包,并用wireshark进行分析流量包,进一步理解了握手过程中Cookie机制和通信双方的认证过程。
最后,这次实验是对我进入矿大后的一次总结吧,充分利用了平常自己和老师在课上教授的各种知识,做到了学以致用。
声明
本文创作时参考的文章如下:
https://blog.csdn.net/hylaking/article/details/89473172
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达,可以邮件至 xingshuaikun@163.com。