基于DICOM标准的TLS网络安全传输技术研究与实现
(内蒙古科技大学信息工程学院,包夹014010)
摘要:随着医疗信息化的发展,图像归档与通信系统(PACS)、医院信息系统/放射科信息系统(HIS/RIS)等医疗信息管理系统日渐普及和完善,这些系统之间的互操作越发频繁,通过网络由一个封闭的系统走向开放,走向区域化成为必然。而信息的传输安全是使之成为可能的前提条件,基于网络安全的必要性,着重研究了医学数字成像与通信(DICOM)标准和安全传输层(TLS)协议,并结合OpenSSL工具包和DCMTK工具包实现了DICOM医疗信息TLS安全传输。

随若计算机和网络技术的发展,信息化的步伐日益加快,特别是以不断完善的医学数字成像与通(Digital Imaging and Communications inMedi-cine,DICOM)标准为依据的医疗信息化。同时,人们对医院行业的要求也越来越高,这要求医疗机构充分利用和共享人力资源和设备资源,形成高效便利的现代数字信息化管理模式。由此,建立和完善区域协同医疗服务信息化体系将成为医疗信息化的重要组成部分,建立区域乃至国家医疗信息系统是一个追切的具有挑战性的话题。当前各类医疗信息系统各自为政的局面,将过渡到系统互联、部门互联、医院互联,甚至全国互联的局面,医疗隐私数据必然将由一个封闭的环境暴露到一个开放的环境中,这样,医疗卫生信息化的安全问题将变得更加重要和突出四。同时,随着医疗信息化的迅速发展,医疗信息安全隐患时有发生,很多医疗信息标准的制定已经意识到了医疗信息的安全性,逐渐形成完善的标准与规范。在医疗信息化发展的大背景下,研究医疗信息网络安全成为了必要。在DICOM标准中,传统的传输方式是符合DCOM通信规则的一般通信方式,只能满足将符合DCOM标准的医疗文件进行网络传输,没有任何的安全性措施。这样,符合DICOM标准的医疗信息在经过转发设备传输过程中,非授权用户可以通过一些技术手段对这些信息进行窃听和修改,并且在通信实体双方毫不知情的情况下进行。DICOM3.0标准为了解决这一安全隐患,在第十五章安全概要中论述了对安全传输层(Transport Layer Security,TLS)协议安全传输模式的支持。TLS安全传输方式可以提供通信实体间身份的相互认证,信息摘要的提取,信息的加密传输和信息完整性验证,从而保证了通信信息的机密性、完整性和不可否认性,确保通信信息的安全性。
概述
1.1TΠS协议及TLS通信过程
TIS协议是IETF以SSL协议为基础提出的一种新的协议。该协议由两层构成:TLS Record Protocol和TLS Handshake Protocol。TLS Record Protocol处于较低一层,基于底层可信任的协议,为
高层协议提供了数据封装、压缩、加密等基本功能的支持。它保证了通信的两个基本安全属性:
(1)私有连接。数据传输使用对称加密算法,对称加密算法的密钥对于每个连接是唯一的,基于密协商协议生存,且加密传输是可选项。
(2)可靠连接。消息传输包括基于密钥的消息认证码(message authentication code,MAC)的消息完整性检查,消息认证码使用安全Hash函数计算。消息认证码可以不使用,这种模式一般只用于另一个协议使用Record Protocol进行安全参数协商时。
TLS Handshake Protocol协议允许客户与服务器在应用协议传输或接收第一个数据字节之前相互认证,协商加密算法和加密密钥。TLS HandshakeProtocol保证了三个基本安全:
(1)两端身份可以通过非对称算法(公钥加密算法)进行认证。身份认证是可选的,但至少要求验证一端。
(2)共享密钥协商是安全的。协商的密钥不能被窃听者获得,对于任何连接,秘密不可被获得,即使是自身能够处于连接中的攻击者也不能获取。
(3)协商是可靠的。没有攻击者能够修改协商通信而不被通信双方检测到的。TIS通信双方成功协商建立关联后,记录协议发出传输请求消息,把数据分成可操作的数据块,还可以选择压缩数据,加入MAC信息,加密、加入头文件,在TCP段中传输结果单元。接收到的数据需解密、身份验证、解压重组,然后才能交付上一层使用。将应用数据首先分块,可以选择对每个数据块分别进压缩,再分别对数据块进行摘要提取,将数据块和相应的摘要一起加密,最后以TCP包的形式发送出去。

原文地址:http://www.cnblogs.com/pxyblog/p/16820321.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性