消息安全（精选8篇）
消息安全 篇1
摘要：为了保证电子商务活动过程中数据的安全性,分析了ebXML消息服务的结构,针对Hermes平台的安全问题,采用XML加密技术,改进了原系统的服务器模块的消息安全处理过程。使用了ECC和AES混合加密的算法,利用DES对原文加密,ECC管理密钥,并通过Java2编程予以实现。研究结果表明,该方法弥补了原系统的安全缺陷,可以在电子商务系统中实现安全的数据交换。
关键词：ebXML,SOAP,XML加密
0引言
基于XML的全球电子商务标准ebXML(electronic business XML)是联合国贸易促进和电子商务中心(UN/CEFACT)和推进结构化信息标准组织(OASIS)共同倡导、全球参与开发和使用的一组支持模块化电子商务框架的规范[1]。在使用ebXML进行电子商务活动时,交易信息、资金、身份资料都要通过网络传输,必须保证这些数据的安全。传统的安全解决方案通常采用SSL技术,不能完全解决ebXML消息面临的安全问题。
本研究在对ebXML消息的研究基础上,采用XML加密技术,提出一种安全的数据交换机制。
1ebXML的消息安全
ebXML消息服务[2](ebMS, ebXML Message Service)位于ebXML的最底层,它描述了消息交换的格式,并描述了如何保证消息的可靠、安全传输,为ebXML提供了消息传输平台。
为了传输不同格式的消息附件,ebMS消息的消息结构是根据带附件的SOAP协议定义的,ebMS消息与应用层之间其他部分的关系如图1所示。
消息的最外层是通信协议信封,定义了消息传递的底层协议,如HTTP、SMTP等。SOAP协议中使用MIME(Multipurpose Internet Mail Extension)规范来携带附件,每个附件作为一个MIME部分。
SOAP的信封元素<Envelop>作为根元素,包括消息头元素<Header>和消息体元素<Body>两个一级子元素。而且从<Envelop>根元素开始,消息格式成为一个基于XML的消息包,ebMS消息所有的应用语义也都包含在这个XML消息包中。ebMS消息基于SOAP的扩展主要是指对<Header>和<Body>这2个子元素进行的扩展。
为了保证SOAP消息的安全,IBM, Microsoft等公司在2002年4月提出了WS-Security规范[3]。该规范主要利用SOAP头的扩展来实现安全性,使用的主要技术包括XML数字签名和XML加密。
XML数字签名是将数字签名和XML组合而成的产物,它可以保证XML的完整性并提供身份认证。与普通的数字签名相比,它具有更高的灵活性,可以对部分内容签名,也可以对整个文档签名。
XML加密能保证敏感信息不会泄漏。对于ebMS消息来说,XML加密的优点是它支持对ebMS头部元素的选择性加密。也就是说,使用像S/MIME和PGP/MIME这样的既有机制,加密整个MIME部件是容易的。
2Hermes平台的安全问题分析
Hermes[4]是由香港大学CECID(Center for E-Commerce Infrastructure Development)采用纯Java开发的一个典型C/S结构的开源ebMS平台,它具有跨平台、完全遵循ebMS规范、通过了互操作性测试等优势。此平台在2005年最终完成,现已被广泛应用于商务、政府、医疗等领域。
Hermes平台采用C/S结构,客户端通过公网与服务器交换商务信息。为保证安全性,服务器端对ebXML消息进行签名,并采用SSL技术保证了传输过程中的机密性,但在服务器端ebXML消息仍是明文,容易被攻击者进入服务器后窃取,没有实现对消息的持久加密。而且,基于SSL的加密只能提供传输层安全,这种级别的安全性只能提供点到点的安全性[5],而在实际的电子商务数据传输过程中,数据在传输过程中通常需要跨越很多中间结点,假如应用程序对ebXML消息进行恶意破坏,可以在ebXML消息中插入一系列相似的头元素,再传给下一个节点,从而破坏了信息的完整性,因此SSL不能保证端到端的传输安全性。另外,SSL必须加密整个文档,不能进行部分消息的加密,缺乏灵活性[6]。
3Hermes的改进和实现
针对以上问题,本研究在对Hermes平台进行源码级分析的基础上,在安全性方面对其进行了改进,在Hermes服务器端加入了XML加密功能。XML加密并不是用于取代SSL,它所提供的是用于SSL未涵盖的安全性需求的机制[7,8],包括加密XML的一部分和多方之间的安全会话,用于系统中对重要的商务消息进行加密,保证消息持久的机密性,并结合原系统的数字签名功能,提高整个平台安全性。
Hermes平台由1个客户端模块和1个服务器端模块组成,服务器端模块又叫MSH(Message Service Handler)模块。MSH主要包括如下模块:消息监听及接收、数据存储、消息安全处理、安全可靠传输、日志管理系统,其总体架构图如图2所示。
本研究在原MSH模块的基础上,加入XML加密功能,完成对发送信息的XML加密和对收到信息的解密处理。XML加密、签名及解密、签名验证过程在整个MSH模块中所处的位置如图3所示。当客户端模块有消息要发送时,MSH模块会对消息进行XML签名及加密,然后通过ebMS可靠传输机制发送信息,并同时存储信息;当收到来自其他MSH的请求消息时,首先对消息进行XML解密及签名验证,验证无误后根据消息类型进行相应处理。如是商务信息,则存储信息,当相应Web客户端查询信息时,作为响应信息发送给客户端。
本研究的加密方案采用了两类加密算法:AES(Advanced Encryption Standard)和ECC(Elliptic Curve Cryptography)。其中,AES是对称加密算法,加密速度快,适合加密明文,但是密钥管理困难。ECC是一种公钥密码算法,安全强度较高,密钥管理简单,但是加密速度相对AES较慢。因此,将AES和ECC相结合,使用AES加密明文,ECC生成传递AES使用的密钥的数字信封,这样可以有效地提高加密效率,并简化密钥管理。
基于通用性和规范等方面的考虑,本研究采用了开源第三方解决方案:Apache XML Security (http://xml.apache.org/security/)和Bouncy Castle JCE(http://www.bouncycastle.org/)实现XML加密处理。
XML加密概括起来讲就是一个构建EncryptedData元素及其子元素的过程,过程如下:
(1) 首先生成加密XML信息的AES密钥和ECC密钥对。使用此ECC公钥加密AES密钥,并构建EncryptedKey元素。
(2) 导入被加密的ebXML文件,使用AES加密算法加密需要加密的消息明文,构建EncryptedData、KeyInfo元素,并将KeyInfo元素包含到EncryptedData元素内部。指明被加密元素,完成加密处理。
4结束语
良好的安全性是电子商务广泛开展的基础,笔者在研究ebXML消息结构的基础上,对开源平台Hermes在安全性方面的不足提出了改进并实现,采用AES和ECC混合加密的方案实现了XML加密功能。该方案弥补了原系统所使用的SSL加密在安全性上的缺陷,实现了加密速度和密钥管理之间的平衡,具有较高的实用性,可用于电子商务中以保证交易信息的安全。
参考文献
[1]陈恭和,昊晨.ebXML技术框架-全球电子商务的革命[J].中国金融电脑,2001(12):8-12.
[2]OASIS ebXML Messaging Services Technical Committee.ebXML Messaging Service Specification,Version2.0[M].OASIS ebXML Messaging Services Technical Committee,2002.
[3]刘君强,钱肖英.基于WS-Security的SOAP消息的安全规范[J].电脑知识与技术:学术交流,2007(2):964-966.
[4]YEE P.Hermes Message Service Handler DevelopmentGuide,Version1.0[EB/OL].[2005-08-12].http://www.freebxml.org/mshdownload_1001.htm.
[5]张广梁,孟晓景,徐占鹏,等.Web服务消息级安全通信研究[J].科技资讯,2007(20):129-130.
[6]毛春丽,吴献文.基于SOAP安全技术的电子商务安全性研究[J].网络安全技术与应用,2006(7):47-50.
[7]SIDDIQUI B.Exploring XML Encryption,Part 1.Demon-strating the secure exchange of structured data[EB/OL].[2002-03-01].http://www.ibm.com/developerworks/library/x-encrypt/index.html?S_TACT=105AGX52&S_CMP=cn-a-x.
[8]王凯,刘鎏,李际军.基于中间件的企业基础信息交换系统[J].机电工程,2007,24(12):9-12.
一种web服务消息级安全模型 篇2
一、传输级安全与消息级安全的比较
从web service安全保障的处理层面来说, 传输级安全与消息级安全是两大主要的保障机制。
传输级安全主要是使用SSL来保障传输通道的安全, 然而这种安全具有如下局限性:
1、没有解决身份认证的问题, 必须结合其他机制, 才能处理认证问题。
2、传输级安全针对整个通道加密, 必然影响系统性能。
3、SSL是一个点到点 (point-to-point) 的安全协议, 不适合端到端 (end-to-end) 的拓扑结构, 在端到端的结构中, 消息需要通过网关等设备进行传送。
而对于消息级安全, 安全限制被运用于消息本身而非传输通道, 可以在很大程度上提高操作效率;同时消息级安全在web service的通信协议 (SOAP) 之上实现, 也满足了端到端应用的需求;另外, 消息级安全作用于web service的数据格式 (XML) 之上, 扩展性、灵活性等都是与生俱来的。
二、消息级安全模型设计思路
2.1 web service的通信格式
在应用层, web service采用SOAP (简单对象访问协议) 作为其通信协议 (SOAP协议可以承载在http, stmp等具体的应用层通信协议之上) , SOAP消息的格式十分简洁:由Envelope元素包含header和body元素, 其中header元素和body元素又分别包含若干子元素, Header元素为可选元素, 用于存放控制或者辅助信息, Body元素用于存放具体的数据以及错误信息。
2.2利用SOAP Header对消息进行责任链式安全处理
在实际的应用系统中, 对系统安全性的要求是多种多样的, 并且可能是经常变化的, SOAP提供的一组可选的Header信息正好可用来存放访问控制、加密算法等相关安全信息;同时考虑到SOAP消息在端到端之间进行传递时, 可以为用户提供在发送、接收消息过程中解析、处理Header信息的机制, 所以完全可以设计一种针对web service的, 责任链 (Chain of Responsibility) 模式的消息级安全模型, 在适当的时机截取SOAP消息, 利用功能独立、相互之间松散耦合的消息处理类构建起消息处理的责任链, 按照既定的顺序去处理不同的Header信息中存放的web service安全信息, 从而达到保障web service安全的最终目的。图1展示了模型的消息处理机制和消息处理过程。
目前, 围绕web service安全性, 已经有了很多的相关技术和标准, 但是不管使用什么技术, 要使信息能够安全到达对方, 必须对信息进行安全处理, 责任链式的消息级安全模型可以在客户端发送信息之前对信息进行处理 (如加密或者签名) , 然后将消息再发送出去;在服务端接收信息之前进行逆向或者验证处理 (如解密或者验签) , 再将消息派发到目标服务 (同时也可以在服务端返回响应的时候做类似操作以保证端到端消息通道的双向安全性) , 从而达到对web service消息进行安全控制的目的。
三、模型在主流SOAP框架下的实现思路
目前, 主流的SOAP框架主要有Apache Axis和Codehaus xfire, 虽然由于简单易用和处理效率高等原因, xfire有后来居上的势头, 但是两者均能实现本文所描述的责任链式消息级安全模型。下文以一个简单的、通过hash算法验证消息完整性的实际应用场景来描述模型在axis框架下的实现。
3.1总体设计
按照上文图1体现的消息处理机制, 设计四个处理对象 (每个对象都实现BasicHandler抽象类, 通过抽象方法invoke来对消息进行处理) 以在客户端请求组装, 服务端接收请求, 服务端响应组装和客户端响应接收四个时机对消息进行处理, 而实际上, 通过上文图1可以看出, 每个时机上的handler是可以有多个的, 所以该模型能够随时通过在每个时机上添加新的、功能独立的handler来完成新的安全限制, 以应对应用系统不断变化的安全需求。
3.2具体实现代码片断
※客户端的具体实现片断
※服务端的具体实现片断
服务端收到客户端的请求之后, 从body中取得业务数据的内容, 根据事先约定好的算法对其进行hash运算, 然后将运算结果与header中存放的hash结果进行比对, 比对通过就进行后继步骤, 不通过就返回错误即可。从代码结构上来说与客户端的代码结构基本一致, 从配置文件的内容来看与客户端的配置也大致类似, 这里就不给出具体的代码和配置文件的片段了。
需要说明的是:上述代码片断只描述了消息传递的一个单边的过程, 即客户端组装请求、发送请求, 到服务端接收并处理请求的过程, 至于另一边服务端组装响应、发送响应、客户端接受并处理响应的过程在安全处理方面是类似的。
四、结束语
本文提出的消息级安全模型, 完全支持现有的与web service消息级安全相关的各类技术和标准 (如WS-Security, XML Digital Signature等) , 相对于传输级安全具有更高的操作效率和更广的应用范围, 而且其松散耦合的结构特点使得其能够被很方便的扩展以满足各类不同的安全需求。另外, 该模型能够在现有主流的SOAP框架下实现, 充分表明了该模型实际应用的可行性和使用价值。
参考文献
[1]Martin R C.敏捷软件开发:原则、模式与实践[M].邓辉, 译.北京:清华大学出版社.2003.
绘本《好消息，坏消息》教案 篇3
1.能基本理解故事内容，并能用清晰的语言表达自己的感受。
2.尝试用辩证的思维去理解“什么是好消息，什么是坏消息”。
活动准备：
绘本、PPT、图片
活动过程：
1.导入：
今天，老师带来一本有趣的绘本书，大家一一下里面会发生哪些有趣的事呢?
(幼儿集体默看PPT画面)
2.交流、分享：
师：“刚才你印象最深的是哪一幅画面?
幼：“啃苹果发现小虫”、“小老鼠找回筐子”、“他们爬旗杆被电黑”......
师：刚才大家看的是一本关于好消息和坏消息的绘本，现在请和身边的朋友一绘本，看看书中哪些是好消息，哪些是坏消息?
(幼儿两人一本共阅)
师：你刚才看到书中哪些是好消息，哪些是坏消息?
幼儿边说，老师边贴出相应场景
我们一一看，在所有的消息中，小白兔是什么表情、小田鼠又是什么表情?为什么有的消息小田鼠认为是坏消息、而小白兔却认为是好消息?
(引导幼儿讨论)
：同样的消息，不同的角度和心态会有不同的感受。为什么当小田鼠大发脾气时，一直都很高兴的小白兔会伤心的哭起来?这时小田鼠又是是怎么想的?让我们边思考、边完整的欣赏一遍故事。
(幼儿边看PPT画面，边听老师声情并茂地讲述故事)
3.延伸
(1)讨论小田鼠最后想了什么、做了什么?为什么会这样?
(2)引发幼儿进一步思考：我们生活中遇到一些事情时，该怎样以积极的心态去看待?
活动反思：
消息安全 篇4
Web Services是分布式计算的重要标准, 也是未来软件开发的技术趋势, 通过Web Services, 应用软件之间可以实现跨平台, 跨编程语言的联接和互操作。Web Services是利用XML来传递消息的, 而X M L消息传递的行业标准协议是S O A P (Simple Object Access Protocol) , 服务的调用者通过在如HTTP等传输协议上绑定SOAP消息来请求服务。SOAP在制定时并没有过多考虑安全性要求, 针对Web Services使用中突出的安全问题, IBM, 微软, VeriSign和Forum Systems等开发了WS-Security (现由Oasis-Open下的一个委员会开发) , 给出了Web Services的SOAP消息安全规范。
1 Axis2及Rampart介绍
Axis2是Apache新的Web Services框架, 它体现了从Axis1.x系列获得的经验和Web Services领域的新发展。Axis2不仅拥有更好的性能, 还添加了一些新特性和功能, 如:使用更高效、灵活的新XML对象模型AXIOM;可扩展消息传递引擎;可插入模块的体系结构。
Rampart是Apache Axis2的实现了WS-Security安全规范的安全模块, 因而具有模块的易插入性。从图1可见, SOAP消息的处理类似一种“管道流”的形式, 即分别在SOAP消息的输入和输出的安全处理阶段 (security phase) 添加两个handler:Rampart Reciever和RampartSender。
“RampartReciver”handler拦截输入的SOAP消息, 然后交由Rampart进行安全校验 (如签名验证、解密、用户验证等) , 所有的安全处理都在Rampart模块内部完成;类似的, 程序的结果消息在输出前被"Rampart Sender"handler拦截, 做安全处理后 (如加密、签名等) 再输出。可见, Rampart相当于在原Web Services应用的各处理阶段里插入了一个安全处理阶段, 可以在几乎不影响原程序业务的情况下为Web Services加入安全特性, 体现了消息传递引擎的可扩展性。
2 一个基于Rampart的SOAP消息安全模型
下面是基于Rampart的SOAP消息安全模型示意图 (图2) 。
在模型中, Web Services应用加入Rampart后, 可以方便地通过X M L数字签名保证S O A P消息的完整性和不可抵赖性;通过XML加密可以保证消息的机密性;通过对不同的接受者使用不同的加密密钥来加密消息的不同部分, 可确保消息在多方间传递时的机密性;还可以为模型加入用户身份令牌环 (usernametoken) 认证, 用于用户身份的识别和验证。
使用此模型, 首先需要使用SUN的密钥和证书管理工具Key Tool产生一对密钥仓库文件:service.jks和client.jks, 分别由服务端和客户端携带。这对key pair里包含了如密钥等重要信息, 而且keytool允许用户指定任何注册了的加密服务提供者所提供的密钥对的生成和签名算法。程序使用类似如下内容的一个properties文件配置和使用jks:
下面介绍如何在Web Services应用中使用Rampart:首先根据使用的Axis2-1.X版本选择相应1.X版本的Rampart, 然后将Rampart提供的Modules目录里的rahas-1.X和rampart-1.X两个mar文件放入Axis2_Home的module文件夹, 修改axis2.xml, 加入
加载Rampart模块后, 便可以通过两个配置文件来为Web Services加入相应的安全特性:服务端是在services.xml, 而客户端则是在axis2.xml。在客户端和服务端都进行了Rampart的安全配置后, 两端就可以使用jks文件对SOAP消息进行数字签名和加密等应用 (Rampart配置和jks文件的使用将在例子中展示) 。
3 模型实现示例
下面将基于模型实现一个例子, 即利用签名保证SOAP消息的完整性和不可抵赖性。
3.1 安全回调类 (CallbackHandler)
该类是实现用户令牌环 (username Token) 身份验证和传送信息的安全性和完整性的核心, 被配置在客户端axis2.xml和服务端services.xml中。每当客户端发送请求时, 它都要首先通过该类获得访问服务端的权限和获得发送数据所需要的加密密码, 然后把数据加密发送给服务器端, 如果没有权限则不能把数据发送到服务器端, 每当服务器端想要把数据传送到客户端时, 也要经过此类获得发送数据所需要的加密密码, 然后把数据加密返回给客户端, 客户端通过解密获得明文信息。由于例子简单, 服务端和客户端的CallBack类可以通过代码手段做成一样, 此CallBack类主要代码如下:
3.2 服务端代码
可见此服务端类只简单返回消息, 不需要继承任何基类, 仅通过services.xml和其他部分联系。
3.3 服务端配置文件services.xml
从以上主要代码可见, Service Class标明了服务端类路径, 然后通过
3.4 客户端代码
首先需要载入配置文件axis2.xml:
其中略去了简单的传送字符串"Hello world"与包装后SOAP消息、传送结果时使用的OMElement对象三者之间的转换代码。
3.5 客户端配置文件axis2.xml
各个配置参数与services.xml中基本类似。当然, client.jks里携带的是服务端公钥以解密收到的服务端信息, 还携带客户端私钥以加密从客户端发送的信息。
3.6 运行结果检验
程序的直接运行只能看到是否成功及成功传送的信息, 此处可使用TCPMonitor工具来查看在本机内运行的详细结果, 以服务端收到的SOAP消息为例, 见图3。
可以看到, S O A P消息的H e a d e r里多了一个
Digest Value包含在Signed Info。后面对Signed Info签名时就相当于间接对引用对象做了签名, 签名值放在Signature Value元素, 从而保证其完整性。服务端对接到的SOAP消息做两个验证:“引用Reference的验证” (即比较是不是和Digest Value里摘要值相等) 和“签名Signature的验证” (即比较是不是和SignatureValue值相等) 。如果验证都通过了, 说明消息是完整的, 没有被改动过。如果使用非对称加密 (比如例子) , 则在验证通过后还可以得到“不可抵赖性”的效果, 因为密钥只有特定用户知道, 不能仿冒。
服务端往客户端发送的SOAP消息是类似的, Header元素同样包含了摘要值;而SOAP的Body里则包含了返回消息, 即客户端代码里的返回值response, 这个OMElement类型的变量封装了真正的xml消息片段“Hello world, 如下所示:
4 使用Rampart进行其他安全扩充
在上面的例子里通过使用Rampart很方便地实现了SOAP消息的数字签名, 保证了消息的完整性和不可抵赖性。事实上, Rampart对令牌环用户令牌环 (usernameToken) 身份验证、XML Encryption等都做了很好的实现支持, 只需更改例子中的services.xml和axis2.xml以及CallBack类的代码就可以添加这些新的安全特性, 不需要改动服务类和客户端原来的业务代码类, 这是很大的优点。
以给客户端发送消息时加入最简单的口令不加密的令牌环示例如下, 只需要在客户端axis2.xml里配置一下输出流:
然后相应地对服务端services.xml的输入流Inflow Security做令牌环验证的配置, 以及在CallBack类中校验令牌环内容以识别用户即可, 见如下CallBack类代码片段:
除了对原有业务代码影响小外, Rampart也非常灵活, 易于扩充和更改, 要更改使用的加密算法、更换密钥等都很易于在X M L配置文档中设置。比如, 数字签名和X M L加密等可以进行很精细粒度的配置, 可以配置只运用到消息的某个元素直至运用到整个消息;令牌环中的密码类型可以更改为选用特定算法做摘要后再传输等。这种强大和灵活正是Rampart的优势所在。
5 结论
本文研究了SOAP消息的安全问题, 基于Rampart给出了一个实现SOAP消息安全的模型, 该模型可以方便、灵活地实现SOAP消息的安全性, 为Web Services应用提供了消息级安全的保障。
参考文献
[1]刘志都, 贾松浩, 詹仕华.SOAP协议安全性的研究与应用.计算机工程.2008.
[2]Nils Gruschka, Meiko Jensen, Torben Dziuk.Event-based Ap-plication of WS-SecurityPolicy on SOAP Messages.Nov.2007.Proceedings of the2007ACM workshop on Secure web services.
[3]Carlos Gutiérrez, Eduardo Fernández-Medina.Mario Piattini.Web Services Enterprise Security Architecture:A Case Study.Nov.2005Proceedings of the2005workshop on Secure web services.
消息安全 篇5
由于高的碰撞率 (collision rate) 和终端隐藏 (hidden-terminal) 使得VANET中的广播通信可靠性下降[3]。IEEE 802.11广播模型不采用RTS/CTS (request-to-send/clear-to-send) 的握手过程, 这是因为其假定消息发送者的通信范围内所有节点都是消息的接收者。因此, 潜在的隐藏终端的区域比802.11单播模型更广, 这会导致通信可靠性下降。
处理碰撞和终端隐藏问题的传统方法就是假定单跳场景 (single-hop scenario) , 并将些场景所获得的结果扩展到多跳场景。此方法不能有效处理碰撞和终端隐藏问题, 也无法获取系统的动态性能。文献[4, 5]基于上述假设进行VANET性能测量。例如, 文献[4]充分利用该假设评估单跳场景内的碰撞概率和吞吐量性能。
实际上, 在VANET中共存两类应用。为此文献[6]提出了分析VANET的两类应用的主要性能的理论模型。与其他方案不同, 该模型是基于多跳的角度, 而不是单跳, 能够获取系统的动态性能, 如终端隐藏活动。然而, 该模型将介质访问控制MAC (medium access control) 的退避时间 (backoff time) 作为消息的间隔时间 (inter-arrival time) , 降低了系统的性能。
为此, 本文首先引用IEEE 802.11 MAC协议作为广播模型, 仅当产生新的消息才出现backoff过程。在VANETs中, 广泛采用广播去分发安全消息, 将邻近的车辆作为目的节点, 减少了在MAC层处理时间。然而, 由于缺少RTC/CTS的握手连接以及消息确认环节, 使得通信更容易受到干扰, 降低了通信的可靠性。
将网络状态表示为 (n, k) , 其中n、k分别表示在backoff阶段, 低级 (low-priority) 传输并发数;低级 (low-priority) 消息数。因此, 依据二维马尔可夫过程 (2-D Markov process) , 提出传输消息数以及backoff过程模型。通过该模型能获取性能参数。在此, 仅关注在存有low-priority消息传输的情况下highpriority的端到端传输时延 (end-to-end delay) 。最后, 进行系统仿真, 并验证理念分析的正确性。
1 网络模型
考虑一维的VANET高速场景, 长度为R m。节点传输范围为d m, 并假定节点在传输期间, 节点是静止的。
依据文献[7]实验结论, 假定节点进入高速公路服从泊松分布, 参数为φ, φ表示每段高速公路有φ个节点。因此, 节点的位置服从均匀分布。将网络中的节点分为两种状态:忙、空闲。空闲节点表示该节点无消息传输, 忙节点表示该节点正在传输消息要或处于退避阶段 (backoff process) 。
考虑两类消息流量。第一类为低级 (low-priority) 流量, 其服从以参数λ0的泊松过程。λ0表示每秒每辆车的消息数[4,8]。假定只有空闲节点才产生新的消息, 因此, 每个节点等待传输的仅一条突出消息。定义λ作为泊松消息到达率, 即λ=φλ0。第二类为事件驱动高级消息 (event-driven high-priority messages) 。两类消息传输时间都服从指数分布, 参数为μ。
在任何特定时间, 并发传输的数目可将网络分为交替活动区域 (alternating activity) 和不活动区域。在活动区域内, 至少有一条正在传输的消息。定义干扰子区域IS (interference sub-region) , 其表示处于活动区域内的两个并发节点传输范围的重叠区域。只要目的节点不位于IS内, 就假定目的节点能正确接收消息。此外, 如果传输节点 (发送节点) 本身就处于IS内, 将此干扰称内部干扰IIF (internal interference) , 否则称为外部干扰EIF (external interference) 。
假定n个并发传输节点数, 则所有活动区域的平均长度为有h (n) 个干扰子区域, 分别如式 (1) 、式 (2) 所示。
式中, 表示n个并发传输活动区域的平均数, 即其中, Qm (n) 表示m (n) 的概率分布。Pc、Ph分别表示内部干扰、外面干扰的概率, 如式 (3) 、式 (4) 进行计算。
式中, P'c、P'h分别表示重叠概率, 可由式 (5) 、式 (6) 进行计算。
式 (5) 中, ξ表示竞争时隙 (contention time slot) 的持续时间。
2 分析模型
本小节, 为低级流量 (low-priority traffic) 通信提出理论模型。依据IEEE 802.11MAC广播模型, 空闲节点产生消息, 如果节点能在分发的帧时隙找到空闲的媒介就立即传输此消息, 否则就随机设定退避计算器, 并递减直到有空闲的媒介。因此, 任何到达处于活动区域的空闲节点的消息会引用退避的初始化, 而到达处于非活动区域的空闲节点的消息会立即传输。此外, 处于退避阶段的节点和位于活动区域的节点不能递减计算器。
图1显示在时间Δt内传输活动实例。如图1 (a) 所示, 节点1、3、7正在传输数据, 而节点2、4、6和8正在接收数据。节点4、6、8已在MAC层接收了数据, 正等待传输。然而, 由于处于活动区域, 它们需安排退避计数器。注意到图1 (a) , 节点2处于干扰区域。图1 (b) 显示了图1 (a) 经Δt后结果。从图1 (b) 可知, 节点3、7完成了它们的传输, 而节点1仍在传输。节点5已接收了消息并开始传输。此外, 节点4、8检测到空闲的媒介并开始递减退避计算器, 而节点6仍检测到媒介是忙, 因此节点6的退避计算器仍处于不工作状态。
设置退避竞争窗口尺寸为ω、退避时隙的持续时间 (duration) 为α。
(1) 一条新的消息到达处于活动区域的空闲节点的MAC层时, 网络状态将从 (n, k) 变为 (n, k+1) 。活动区域内每米的空闲节点数可表示为。因此, 处于活动区域的空闲节点数可表示为。到达空闲节点MAC层的消息率 (消息/s) 可表示
(2) 当一条新消息到达处于非活动区域的节点MAC层时, 网络状态将从 (n, k) 变为 (n+1, k) 。由于处于非活动区域内的节点不能传输消息, 非活动区域内每米空闲节点数可表示为φ-k/R。网络内非活动区域平均长度为非活动区域内空闲节点数目为。因此, 非活动区域内节点产生消息率可表示为
(3) 当消息传输完成后, 网络的状态由 (n, k) 变为 (n-1, k) 。若传输的消息为n, 则消息传输率则为nμ。
(4) 若在非活动区域完成了消息退避, 网络的状态从 (n, k) 变为 (n+1, k-1) 。
如果出现下列四种情况的任何一种, 网络将进行 (n, k) 状态。
(1) 在网络状态为 (n+1, k) 下完成了某条消息传输, 状态变为 (n, k) 。
(2) 在网络状态为 (n, k-1) 下, 一条新消息到达活动区域的MAC层, 状态变为 (n, k) 。
(3) 在网络状态为 (n-1, k) 下, 一条新消息到达非活动区域的MAC层, 状态变为 (n, k) 。
(4) 在网络状态 (n-1, k+1) 下, 在非活动区域完成了一条消息退避, 状态为 (n, k) 。
接下来, 设定pn, k (n, k) 表示网络状态 (n, k) 处于稳定状态的联合概率。利用2-D马尔柯夫过程 (Markov process) 进行描述, 如式 (7) 所示。
式 (7) 中nmax、kmax分别表示消息在传输阶段、退避阶段的上限。
依据给定的传输率, 可得稳定状态全局等式, 如式 (8) 所示。
式 (8) 表示nmax×kmax平衡方程组, 通过该方程组求解nmax×kmax联合概率。然而, 此方法不具有可操作性, 因为nmax×kmax太大。为此, 选用另一种方法求解。
设定条件概率pn|k (n|k) 表示在退避阶段有k条消息的条件下有n个并发传输的概率, 反之亦然, pk|n (k|n) 。接下来, 在状态 (n, k) 下, 定义下列符号:
(1) an|k (n) :并发传输数量的生率BR (birth rate) 。
(2) bn|k (n) :并发传输数量的灭率DR (death rate) 。
(3) ak|n (k) :处于退避阶段的消息数量的生率BR (Birth rate) ;
(4) bk|n (k) :处于退避阶段的消息数量的灭率DR (death rate) 。
依据式 (8) , 可分别得到式 (9) ~式 (12) ,
依据文献[9]的算法, 可得式 (13) 和式 (14) :
通过求解不等式获取并发传输的最大值nmax。接下来, 假定kmax=nmax=max (kmax, nmax) , pk (k) 、pn (n) 分别表示n、k的边缘分布 (marginal distributions) , 则相应的全概率分别如式 (15) 、式 (16) 所示。
为了计算边缘分布, 以矩阵的形式扩展上述方程组。定义nmax×nmax矩阵Pn|k, 该矩阵的第n行、第k列元素为pn|k (n|k) 。同时, 定义nmax×nmax矩阵Pk|n, 该矩阵的第n行、第k列元素为pk|n (k|n) 。因此, n、k的边缘分布矢量Pn、Pk。依据式 (15) 和式 (16) , 可得:
接下来, 分别表示n、k的平均数, 即
式 (22) 中, pn (i) 、pk (j) 分别表示Pn、Pk的第i、j元素。
最后, 可得联系概率:
3 High-Priority消息分发时延分析
本节, 将分析针对事件驱动安全流量的消息分发平均时延。由于high-priority流量属事件驱动型的, 不是频繁地产生, 可假定转发high-priority消息的节点将经历low-priority流量, 如式 (9) 所示的an|k (n) 。由于节点服从均匀分布, 可得low-priority传输的间隔时间的概论密度函数PDF (probability density function) , 如式 (22) 所示。
式 (22) 中, 2d表示high-priority转发节点的传输范围[10]。在时隙α内, 在转发节点的通信范围内无新low-priority传输的概率为Ps (n, k) , 结合式 (22) 可得。将Ps作为Ps (n, k) 无条件概率, 可得
接下来, 分析第h个中间节点的传输时延。由于第h个中间节点是从第h-1个中间节点收到high-priority消息, 其不可能处于活动区域, 该节点在DIFS (distributed interframe space) 时期一直监测媒介。因此, 它以概率Ps找到空闲的媒介, 并于下一个时隙传输。在这种情况下, 转发时延为α+, 为平均传输时延, =1/μ。换而言之, 该节点以概率1-Ps监测到媒介忙, 为此, 它必须等待正在传输消息以及退避阶段完成后, 才开始传输。因此, 转发时延为:0.5α++E[backoff time]+。第h个转发节点的平均时延可表示为
接下来, 分析式 (24) 中的E[backoff time]的值。不失一般性, 假定high-priority与low-priority的退避窗口尺寸一样。第h个转发节点选择的退避值为i, 且i=0, 1, …, ω-1。
接下来, 讨论源节点 (h=1) 的安全消息传输时延。当源节点产生了high-priority消息, 其可能处于活动区域。假定该事件概率为Pi。在这种情况下, 源节点随机设置其backoff值, 并等待空闲的媒介。由于在活动区域内high-priority消息到达呈均匀分布, 源节点等待空闲媒介的平均等待时间为0.5。如果源节点不在活动区域, 其产生的时延如式 (24) 所示。
因此, 源节点所产生的平均传输时延可表示为
式 (26) 中, 依据文献[11], 可得
最后, H跳的通信传输所产生的总的时延如式 (27) 所示。
4 仿真与分析
利用MATLAB软件构建事件驱动 (event-driven) 仿真平台。针对两类消息, 引用IEEE 802.11p MAC协议, 并结合文献[11]所述的移动模型。该移动模型假定车辆到达服从泊松分布, 参数为ρ (车/s) 。道路为单向的高速公路, 长度为R (m) 。节点以随机性的时间间隔移动, 将此移动间隔称为移动时元mobility epoch, 其服从指数分布, 参数为δ。在每个时元内, 节点以恒速移动, 数值从高斯分布G (η, σ2) 选取。
该模型能准确获取高速网络内车辆移动的主要特性[12], 具体的仿真参数如表1所示。网络节点密度为车辆/m, 相应地节点到达率ρ=2.73车辆/s。在仿真过程中, 考虑三类消息到达率, 即λ0=10, 20, 30。因此,
依据式 (19) 、式 (20) , 图2显示了并发传输平均数和退避阶段的消息平均数。从图2可知, 随着传输范围的增加, 随之减少, 而随之下降。此外, 当传输范围一定时, 消息到达率λ的增加随之增加。
依据式 (31) , 图3、图4显示了在H=5跳的high-priority消息传输时延。图3显示了分发时延随传输范围d的变化情况, 以传输范围d为变量, 以消息到达率λ为参数。而图4是以消息到达率λ为变量, 以传输范围d为参数。从图3、4可知, 传输时延随λ、d的增加而增加。然而, 图3与图4的曲线增长趋势不同, 从图3可知, 传输时延随传输范围d呈线性增加, 而从图4可知, 传输时延随λ增加曲线具有更陡的坡。这个结果有利于设置最大的传输范围。例如, 当λ=3, d=700时, 平均转发时延约500 ms, 即5跳通信产生了500 ms的延时, 也就相当于一跳产生100 ms延时。依据DSRC[11]所规定的, 对于安全消息可接受的最长传输时延为100ms。因此, 为了确保通信的可靠性, 传输范围就不能大于700 m。此外, 如图4所示, 在d=800, λ=2.7, 传输时延大于500 ms。因此, 应当减少传输时延以保证传输的可靠性。
5 总结
周期性的消息和事件驱动性消息应用具有不同的优先级, VANETs在部署时应当考虑这点。为此, 通过利用IEEE 802.11 MAC协议广播安全消息, 推导出在传输和退避阶段的低级消息数目的联合概率。提出的模型具有普及性, 能够用于基于高速场景的VANETs不同性能测量与分析。通过分析, 推导了高级消息的多跳时延, 也验证了网络连接率随传输范围增加而增加这一普识。传输范围的增加, 提升了消息的退避时间, 从而导致高的多跳传输时延。因此, 必须在传输范围与端到端传输时延之间进行合适的折衷, 特别是事件驱动型消息, 其对传输时延相当敏感。此外, 为了瞬时的高级流量 (highprioirty) , 频繁的低级消息应用应当满足高级消息的传输时延下限。正如前面所提及的, 为了适应IEEE802.11p性能要求, 为高级消息考虑了较小的竞争窗口, 使其能获取最优值。
摘要：在车载网 (vehicular ad hoc networks, VANETs) 中将源节点通信范围内的所有节点看作目的节点, 在介质访问层耗时很小, 因此, 常采用广播通信技术分发VANETs的安全消息。然而, 广播通信缺乏请求发送RTS/清除发送CTS (request-tosend/clear-to-send) 握手连接环节以及数据包确认机制, 通信易受干扰, 促使通信可靠性下降。为此, 提出VANETs中安全消息分发性能评估模型。该模型假定VANETs具有两类级别消息。此外, 考虑IEEE 802.11广播协议并使用二维马尔可夫模型 (2-D Markov modeling) , 推导了低级周期性消息LPPMs (low-priority periodic messages) 在传输模式和退避阶段的数目的联合概率分布, 并利用该联合概率分布推导出高级事件驱动型消息LPEMs (high-priority event-driven messages) 的平均传输时延, 其有利于网络参数间折衷, 如车辆传输范围、安全消息产生率以及介质访问控制MAC (medium access control) 参数, 通过合适地选择参数, 使其满足LPEMs对延时的高要求。
关键词：周期消息,事件驱动型消息,介质访问层,性能分析,车载网
参考文献
[1] Mershad K, Artail H, Gerla M.We can deliver messages to far vehicles, ”IEEE Trans Intell Transp Syst, 2012;13 (3) :1009—1115
[2] An N, Gaugel T, Hartenstein H.VANET:is 95%probability of packet reception safe.Proc Int Conf ITST, 2011:113—119
[3] Sikdar B.Comparison of broadcasting schemes for infrastructure to vehicular communications, IEEE Trans Intell Transp Syst, 2012;13 (2) :492—502
[4] Eichler S.Performance evaluation of the IEEE 802.11p WAVE communication standard.Proc 66th IEEE VTC, Baltimore, 2007:2199—2203
[5] Sahoo J, Wu E H, Sahu P K, et al.Binary-partition-assisted MAClayer broadcast for emergencymessage dissemination in VANETs.IEEE Trans Intell Transp Syst, 2011;29 (1) :61—71
[6] Khabazian M, Assa S, Mehmet-Ali M.Performance modeling of message dissemination in vehicular ad hoc networks with priority.IEEE J Sel Areas Commun, 2011;29 (1) :61—71
[7] Wisitpongpham N, Bai F, Mudalige P, et al.Routing in sparse vehicular ad hoc wireless networks.IEEE J Sel Areas Commun, 2007:25 (8) :1538—1556
[8] Zhang W.Analysis of packet forwarding in VANETs using probabilistic channel model.Proc 69th IEEE VTC, Barcelona, Spain, 2009:1 —5
[9] Hayes J F, Ganesh Babu T V J.Modeling and analysis of telecommunications networks.Oriental Journal of Computer Science and Technology, 2013;6 (1) :67—70
[10] Henty B E, Stancil D D.Dedicated short-range Communication (DSRC) Working Group, 2007, Available:http://grouper.ieee.org/groups/index.html
[11] Khabazian M, Mehmet Ali M.A performance modeling of connectivity in vehicular ad hoc networks.IEEE Trans Veh Technol, 2008;57 (40) :2440—2450
消息安全 篇6
2009年1月5日收到虽然SOA的概念已出现多年,但是在业界和学术界,基于WEB SERVICE 的SOA还是一个正在研究和发展的领域。现在基于WEB SERVICE标准的A2A或者B2B的系统集成越来越多。消息交换是SOA架构中的核心服务之一,它通常是通过SOAP来交换的,因为消息可能传输一些重要的商业信息,所以通过SOAP协议传输的消息的完整性和机密性[1]就需要给予很大的重视。正确使用WS-POLICY [2]和WS-SECURITY [3]这些规范的时候,可以避免XML重写攻击。但是在现实中,人们对这些规范的不正确应用很容易导致系统比较脆弱。
现提出SOAP消息的结构信息的使用,即SOAP Account,它能够有效地防止XML重写攻击。虽然使用SOAP Account可以让合法的消息接收者在接收时较早地探测出重写攻击,但是SOAP Account本身也可能是攻击者的目标,所以要重点分析SOAP Account本身的完整性保护。并且使用WS standards来描述WEB SERVICE的安全架构,重点从消息级别的安全来说明了它的重要性,以一个虚拟的恶意攻击例子来说明怎样实现SOAP Account完整性。
1 术语和技术
1.1 SOA
SOA架构是一种松耦合的服务集合,也就是说,服务是自包含的,松耦合的,不一定完全依靠另一个服务。SOA不是一个新的概念, Microsoft的DCOM技术、基于CORBA中的ORB(Object Request Brokers)技术就是SOA的最初应用。 SOA的基本架构:服务请求者发送一个请求消息给服务提供者,服务提供者返回一个响应消息,服务注册目录用来注册服务,服务请求者可以通过它找到请求的服务。
1.2 SOAP
SOAP[4]为Simple Object Application Protocol 的缩写,是Web Service的标准通信协议,是一种标准化的传输消息的XML消息格式。SOAP请求(request)消息将客户端的服务请求消息发给服务器,如需要调用什么样的服务接口,以及接口参数值等;SOAP答复(response)消息是从服务器返回给客户端的消息,如服务接口实现后的结果返回值或者调用服务时的错误信息等。
2 Web Service 安全
现从各个方面,Web Service描述了一些开放标准(如SOAP,WSDL,UDDI)交互,和不同平台(J2EE,DotNet等)的实现和应用。如此多的技术都在SOA安全方面有所应用,针对SOA的安全方面标准和技术正在快速发展。在这节中,我们简单介绍Web Service安全方面的架构[5] (图1)。
2.1 Web Services安全架构中WS*标准
在端对端的安全方面,WS-Security[2],WS-Policy[3],WS-SecurePolicy[5]和其它的Web Services标准是先后进化的过程。图1是不同的Web Services安全标准和一个简单架构,上述三个标准是这些标准中的核心标准。
WS-Security:描述了怎样提供对SOAP信息的头部提供签名和加密,以及安全tokens,包括二进制的tokens,比如X.509和Kerberos。WS-Security使用现有技术(如加密,签名)去保护SOAP信息的安全。
WS-Policy和WS-SecurePolicy:当SOA在不同的实体(如服务提供者,服务消费者和中介)提供松耦合的服务时,WS-Trust描述了一个框架,它能使Web服务去安全的交互。
2.2 Web服务的典型信息流
使用WS标准,Web服务的典型信息流(图2),服务请求者(request)首先从Security Token Service申请安全token,协议栈按照规则生成SOAP信封,并在WS-Security下的<Security>头标记下增加集成和机密的凭证,头标记块可以包含安全方面的信息给特别的接收者。这种类型的元素也许会在SOAP消息中出现多次。一个经过多个中间介的消息也许会增加多个新的子元素到这个头标记块中。
2.3 一个可能的重写攻击的例子
这里给出一个例子来说明SOAP消息在面对这种攻击时的脆弱性(图3、图4)。
例子:一个在线书店的消费者需要购买一些喜欢的书并为之付费(图3)。每一个成功的请求就会导致一次付费。假设这个SOAP节点(最终的接收者)去处理SOAP的header和body。消费者A为了购买想要的书,所以从他的账户转1 000元到书店
老板B账户上(图3)。一些恶意的攻击者拦截了这个消息并且转换了它的状态:转账1 000元变成了转账5 000元(图4)。一个攻击者能够在SOAP在传输过程中拦截并且处理这个消息,他能插入一个新的假的Header(比如<Bogus>图4),其它的,包括论证和签名都保持不动。因为元素reference URI仍然保留在消息中并保存有原来的值,这也许会导致消费者请求一次却付费数次。
2.4 SOAP Account
针对上面例子中的XML重写攻击,提出了SOAP Account技术,其实就是SOAP消息的元素结构的一个记录,这些元素包括头元素的数量,签名对象的数量,签名对象的继承信息等。
图5显示了SOAP Account消息的结构图,重写攻击主要的利用SOAP消息的结构语法,主要的工作就是在SOAP Account中,去捕捉这些信息的结构,我们使用AddSOAPAccount模型去增加这些信息去SOAP消息中。特别是绑定到WS-SECURITY规范的<Security> 头部。从而来避免XML重写攻击。
3增加了SOAP Account后应对XML重写攻击的情况
为了探测重写攻击,在SOAP消息被发送到它的合法接收者之前增加了SOAP Account信息到SOAP消息中(图6)。为每一个SOAP消息设计和实现了一个AddSOAPAccount模型去计算SOAP Account信息,同时在每一个SOAP处理节点中,有一个相应的CheckSOAPAccount模型去检查收到的SOAP消息的安全性。
SOAP Account本身面对XML重写攻击是脆弱的。因为在整个SOAP Account信息被发送到它的合法接收者之前,攻击者可能会用在节2.3中相同的方法去伪造它,SOAP处理节点中的CheckSOAPAccount模型就是扮演一个安全保护者,去保护任何可能的针对SOAP Account的重写攻击。
为了预防这种攻击,当SOAP消息到来时,CheckSOAPAccount模型会去做一些例行的检查。首先是确保收到的SOAP消息一定有一个SOAP Account头部,如果有的话,然后会验证SOAP Account的签名。如果数个中间介都有它自己的SOAP Account,那么会有一个嵌套的签名。如果上面的验证成功,CheckSOAPAccount模型会继续做下面的工作。图8显示了SOAP消息中有SOAP Account,同时攻击者试图去仿造一个SOAP Account头。这个攻击者增加一个新的头部,同时在新的头部Bogus下面拷贝了一封SOAP Account来使签名有效。但是当CheckSOAPAccount像检查SOAP头部一样检查SOAP Account的头部时,因为SOAP Account头部被拷贝放置在一个新的元素下,所以它不再是一个SOAP Account。模型会立刻一个抛出异常并说这个SOAP Account已经被攻击了,这样我们在对SOAP消息做下一步处理前我们就探测到了这个攻击。
即使这个攻击者提供了它自己的SOAP Account,在进行SOAP Account签名检查时,也将会立刻被检查为无效,原因如下:虽然攻击者提供了它自己更改SOAP结构信息后的SOAP Account消息,但是它不能在已经存在的<Security>标签中提供签名密钥信息。这个<Security>标签中包含信息的合法发送者的密钥信息(图7)。在图7中,合法的发送者是A,他在标签<KeyInfo>中提供了被用作签名验证的密钥信息。另外,一个受攻击的SOAP Account信息将会被放置在一个新的假头部下面(图8是在标签<BogusHeader>下面),这个假的头部将会在CheckSOAPAccount模型的探测过程中被探测到,这个攻击者也可能去插入一个新的<Security>标签和自己的密钥信息去验证加入的SOAP Account,同样CheckSOAPAccount也能使用上面同样地的方法探测到在标签<Security>增加的假密钥信息。所以,这样的重写攻击在SOAP Account的签名检测之前就会被探测到,更进一步,嵌套的SOAP Account签名消息将会使攻击者更难去伪造SOAP Account。这样就避免了XML重写攻击。
4 结论
提出一个有效的保护SOAP消息,避免XML重写攻击的方法SOAP Account,因为SOAP Account本身有可能是攻击者的目标,并论述了SOAP Account本身的集成安全性。其中通过一个真实的商业实例去分析了SOAP Account避免XML重写攻击的过程。还在基于有SOAP Account和没有SOAP Account上讨论了两种不同的信息流,显示了SOAP Account在SOA中的简单应用。考虑到真实世界中的系统可能有成百数千的SOAP消息的交换传输,使用这种方法的性能测试还需要去进一步去研究和证明。
参考文献
[1]祝伟华,周颖,杨丹阳.Web服务的安全性研究.计算机科学,2005;32(6):76—78
[2]Bajaj S,Box D,Chappell D.et al,Web services policy framework(WS-Policy),September,2004,http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy0904.pdf
[3]Bhargavan K,Fournet C,Gordon A D.Verifying policy-based security for web services.In:11th ACMConference on Computer and Commu-nications Security(CCS’04),October2004:268—277
[4]Rahaman M A,Marten R,Schaad A.An inline approach for secure SOAP requests and early Validation.http://www.owasp.org/images/4/4b/AnInlin eSOAPValidationApproach-MohammadAshiqurRaha-man.pdf,December,2005:132—135
消息安全 篇7
发展成熟的数字电视和出现的基于蓝牙和红外技术的多功能遥控器,基本实现了数字电视多媒体消息业务。消息通信会话中,如遥控器向遥控器发送接收消息,需要考虑用户安全和网络安全。同时多功能遥控器[1]中的安全策略功能块可以确保只有合法的注册用户才能授权进行短消息服务,从而保证TVMMS服务器的合法性。为此,笔者设计了提高质量的、互操作的、基于密码学的安全框架,基于数字电视多功能遥控器应用平台,引入了ECC身份认证的TVMMS(Television Multimedia Message Service),并提出了实现方案。
1 基于椭圆算法的TVMMS身份认证
1.1 终端解决方案设计结构
在一定程度上改变人们生活方式的增值业务,是数字电视的发展和传输网络应用于广播电视系统的产物,数字电视运营商急切需要一套安全措施,以适应数字电视网络使用增值业务,来保证各项业务在网络中安全、快速的进行。因此,针对TVMMS系统设计数字电视安全策略十分必要。
短消息平台(见图1)是一个规范、严谨的多媒体体系,其主要任务是:直接面对最终用户接入服务,在有线电视分配网络前端将各个节目平台的数字电视节目与本地节目集成,它接收并验证新终端的注册信息,进行信息状态查询,生成完整的服务信息;在这个部分中,有认证用户合法性模块,按照用户定购的情况,给用户的多功能遥控器授权开通短消息服务。
1.2 新型终端设备的功能
实现各种定制服务,多功能遥控器利用红外线发送信息等文本到特制电缆调制解调器,完成广电网中发送短信及远程控制等功能。
数字电视多媒体增值业务的认证主要通过基于蓝牙和红外技术的多功能通信遥控器实现。该遥控器像手机一样具有短信功能,只是服务的对象不同,可建立起广电用户之间的联系,同时还能对家用电器实现红外万能遥控。除了一般电视遥控器的玩简单游戏和电视节目选择等功能,专用通信多功能遥控器[2](见图2),能开通短消息服务、信息的接收和输入、申请人登录等人机交互功能,从而保障了终端设备数字电视业务的有效开展。
1.3 基于ECC的安全总体分析
数字电视系统中,通信双方的安全信道通过公钥证书建立,公钥证书是申请者所需要的信息与其持有公钥的相互绑定,绑定的有效性通过可信的第三方有权机构对数字证书进行验证实现,数字电视多媒体增值业务安全相关的技术支持保障信息的传递。
TVMMS系统中因为没有发展完备的安全设施,所以采用安全强度较高的椭圆曲线密码体制,目前较为常用的公钥算法是RSA。因当前多功能通信遥控器在初始阶段,希望公钥和签名大小能较小,加密长度增长速度较慢,而且随着安全有效位数的增加,两者的差别更为明显。总结以上分析,选择椭圆加密算法,是基于椭圆曲线上离散点分离尚未解理论的安全度设计。
总体功能结构如图3所示,主要由数字电视数据库、数字电视程序、安全通道、数字电视增值业务用户、TVMMS注册中心、TVMMS安全认证中心组成。
电视多媒体业务安全体系框架中,电视使用者实现对短消息功能等的申请,终端使用椭圆算法生成一对密钥后[3],以多媒体消息规定的格式发送申请。增值业务供应商处理下载TV证书、查询证书信息等请求。经过专用遥控器中的注册模块,用户身份合法性是由注册模块负责检验的。对验证过的申请进行证书签发并发布到数字电视增值业务的证书库中。撤销短消息用户证书后,进行数字签名发布数字电视多媒体清除证书列表。资料盘中安装证书的相关软件如客户端等,申请时为消息用户提供该资料盘。能为各个数字电视通信终端发布椭圆曲线算法数字证书,基于密码学中解析使用椭圆算法产生密钥的安全度设计,为电视终端实现安全交流。
2 数字电视多媒体增值业务中ECC认证系统证书的签发
广电系统中公钥算法运用于数字电视多媒体消息各个模块的设计。本多媒体系统通过资料盘中客服端得到的DTV数字证书来获得椭圆曲线,并根据此椭圆曲线的域参数生成密钥对[4]。
2.1 消息用户提出申请
首先,广电网认证系统初始化。服务管理中的认证模块首先在用户服务管理中认证模块生成根DTV证书,再为其他广电网的通信终端生成数字电视证书,如专用多功能遥控器的注册模块等。然后,数字电视多媒体消息业务能够在存储盘中发现数字电视驱动,数字电视驱动主要功能是:生成用于保密信息的密钥对和消息服务申请的证书格式。用户客户端ECC证书流程如图4所示。
其次,用户使用数字电视中心发放的资料,下载系统的多媒体认证根证书,由资料中的程序解析出初始时广电系统认证服务器的自签名证书,得到公钥和该公钥的域参数。
第三,多媒体结构中利用椭圆算法生成安全防范材料,保障对身份的签名和信息保密传输等。曲线选择的有限域是素数域Fp,则椭圆曲线域参数是一个六元组F=(p,a,b,G,n,h),域参数包含有限区间、系数a和b形成的椭圆曲线[5]和基点G。如果选择特征为2的有限域F2m,椭圆曲线域参数是一个七元组F=(m,f(x),a,b,G,n,h)。随机选取一个统计上唯一并且不可预料的整数作为私钥t,其中t在1~(n-1),根据公钥和私钥的关系,公钥Q=t G,可得到公钥。其中,公钥Q是椭圆曲线上的一点,n表示椭圆曲线域参数中的阶,G表示椭圆曲线域参数中的基点。通过认证模块签发的椭圆算法签名发送给另一方,从中得到公钥,私钥t由用户自己保存,设计出ECC密钥的数据结构。具体流程为:
第四,多功能遥控器注册中心验证申请者[6]拥有与该公钥相匹配的私钥,客户端程序用摘要算法计算证书申请的消息摘要,再用私钥计算电视的椭圆曲线算法数字签名,签名结果和原始数字电视证书申请一起传送给多功能遥控器注册服务器。
数字电视多媒体消息业务申请包括申请信息、签名算法标识符和对证书申请信息的数字签名。客户端程序根据用户的申请信息,证书请求字段主要包括:
2.2 注册中心流程
数字电视增值系统的注册中心主要有注册服务器和操作员组成,对增值业务的用户提出的证书请求、恢复密钥、查询等申请做出审核工作。图5为ECC应用于增值业务注册中心的设计。
多功能遥控器的注册服务器审核用户申请的各类申请,为了得到用户公钥,服务器解析获得椭圆算法签名的证书申请,该签名在位于多功能遥控器的功能块中进行验证。如果验证不通过,注册服务器拒绝用户的申请。多功能遥控器不被授权开通该服务。
证书申请审核通过后,用椭圆算法对多功能遥控器注册服务器的证书申请进行签名[7],封装在消息中,附在电视证书申请上,并递交给增值业务的认证系统。此过程由函数RA_Audit_TVCert Req()来完成。取出数字电视用户证书申请结构中的TVMMSREQ_INFO结构。按照Make_ECCert Req函数中相关签名步骤,用注册服务器的电视椭圆算法私钥对TVMMSREQ_INFO部分进行ECDSA签名,签名算法信息和签名值分别放在sign_alg和signature字段中。
2.3 增值业务认证中心的流程
增值业务系统的认证中心要完成数字电视ECC证书的签发、清除证书列表的签发等工作,因此是整个安全措施的核心部分,ECC公钥密码体制将贯穿认证的整个操作过程。图6a和图6b演示了ECC在数字电视上的应用[8]。
数字电视认证服务器收到多功能遥控器提交的申请后,验证该消息,如果检查未通过,则拒绝授权服务。若通过,从TVCERTBody中获得数字电视证书申请信息,并转化成TVCERT-REQ结构,此时调用函数Make_TVEC-Cert()签发证书。多媒体消息业务认证签发证书发布到数字电视证书库,并返回消息到遥控器。
TVMMS的CA服务器从RA传来的消息TVCERT-Body结构中,取出证书序列号和撤销原因。基于证书序列号服务器连接到数字电视证书库,查询到该证书,并把证书的当前状态改为“失效”[9]。认证服务器将该证书序列号、撤销原因以及撤销消息业务时间添加到stu RE-VOKE结构链表中,为生成CRL做好准备。然后,认证服务器通知注册服务器撤销请求。RA检查后,返回一个消息告知用户证书已经撤销的响应。stu TVREVOKE结构链表设计如下:
数字电视消息业务认证中心服务器将签发的证书或清除证书列表发布到目录服务器中。
3 TVECC数字证书的验证
函数Verify_TVEccert()来完成证书验证[10],输入参数为撤销验证标志位和证书撤销列表及其长度、待验证证书及其长度。函数实现如图7所示。
参考文献
[1]金纯,万正兵.基于广电网的蓝牙红外通讯遥控器设计[J].广播与电视技术,2007(4):117-118.
[2]金纯,陈许,万正兵.基于单向机顶盒的双向增值业务实现方案[J].广播与电视技术,2007(3):134-136.
[3]CHEN T S,HUANG G S.Digital signature scheme resulted fromidentification protocol by elliptic curve cryptosystem[C]//Proc.2002I EEE Region10Conference on Computers,Communications,Controla nd Power Engineering Proceedings.[S.l.]:IEEE Press,2002:192-195.
[4]李建华.公钥基础设施(PKI)理论及应用[M].北京:机械工业出版社,2010.
[5]SEC1v1.5,Elliptic curve cryptography(working draft v1.5.standardsf or efficient cryptography)[S].2005.
[6]RFC3641,Generic string encoding rules(gser)for asn.1types[S].2003.
[7]陆洁茹,朱艳琴.基于ECC认证中心的研究与设计[J].计算机应用与软件,2007(12):38-40.
[8]ROBERT Z.Elliptic curve cryptography support in entrust v1.0[EB/OL].[2010-05-09].http://www.entrust.com/resources/download.cfm/21138/e lliptic_curve_v101.pdf.
[9]陈礼青.基于ECC的动态安全组播密钥协商方案[J].计算机应用与软件,2009(8):35-37.
比尔·盖茨:坏消息就是好消息 篇8
比尔·盖茨认为, 不虚心倾听坏消息, 不用行动变坏事为好事, 就将比瞎子还瞎, 比聋子还聋。听不到坏消息, 就是破落的开始。他说:“应保证坏消息更快抵达, 但你的下属可能会不愿告诉你坏消息。你必须始终乐意接受坏消息, 并对它采取行动。”
比尔·盖茨认为, 应当奖励带来坏消息的人, 而不是让报喜者得喜、报忧者得忧。他说:“对带来坏消息的人应给予奖励, 而不应被视为犯上。业务领导必须倾听来自销售人员、产品开发人员和客户的警告。”此外, “对有意义的失败试验, 应实行奖励。”鼓励报告坏消息, 关键在于领导者。他说:“从战略的高度看, 首席执行官的主要职责是发现坏消息, 并鼓励公司做出反应。”
比尔·盖茨认为, 微软成功的主要经验是始终以失败者的身份从坏消息中汲取有益的营养, 使自己的产品日臻完善。他说:“询问任何在微软工作过的人, 他都会告诉你的是我们始终认为自己是失败者。我们今天仍然认为我们是失败者, 就像在过去20年的每一天里我都认为我们是失败者一样。如果我们不坚持这种看法, 我们的竞争者就会吃掉我们的午餐。坚持听取坏消息, 驱使自己把新特色纳入我们的产品。可能有一天有人会使我们猝不及防, 可能有一天来个暴发户会把微软赶出市场。我只希望这是在50年之后, 而不是两年或五年内。”