MSN安全检查和协商过程

1、文档目的：描述msn会话前的安全协商，安全会话软件条件的判定 假定：川户列表已经建立，并已经能够对msn用户列表的类进行相关的操作目的：判断msn是运行在安全程序z后，并作出相应的动作。如何在双方开始文字消息通信z前进行准确地判定对方是否能够支持安全通信呢？安全通信能力判定，依赖于以下几个方而：a、安全通信能力判定必须在双方正常文字消息交互之前完成；b、安全通信能力的判定对用户必须是透明的；c、安全通信能力的判定不应更改msn自身的通信协议与方式，而是要依赖于msn 自身的通信协议与方式；msn的文字消息通信过程简要的描述如下：（假定 alice 请求与 bob 通话）step 1: alic

2、e向ns服务器请求sb服务器;step 2: ns指派给alice 个sb服务器；step 3: alice通过sb服务器呼叫bob;step 4: sb服务器呼叫bob,将bob加入会话，并通知alice会话建立；step 5: alice与bob通过msg命令携带消息进行通信。通过対msn文字消息通信会话建立过程分析,我们采用如下的方法进行安全通信能力判 定的实现。在step 4与step 5之间加入安全通信能力判断环节,安全程序进行的msn文字消息通信 建立过程如下：step 4: sb服务器呼叫bob,将bob加入会话，并通知alice会话建立；step 4.1: alice端的安全程

3、序向bob发送探测报文，并缓存alice端客户程序发送的msg 命令报文；step 4.2: alice端安全程序等待bob端的探测回应,若无回应，则认为bob端msn客 户程序为普通模式，则alice端安全程序发送普通消息（此消息通知bob安装安全通信软件 并给出url地址）；若收到bob端的回应报文，则认为bob端msn客户程序处于安全程序 之后，双方安全程序进一步进行密钥协商，协商完毕之后，alice端安全程序将缓存的msg 命令报文和之后双方交互的msg命令报文进行加密传输，bob端安全程序作同样的处理；step 5:双方进行安全消息通信。当双方都具有处理安全消息的能力时，交互图如下:

4、双方同时具有处理安全消息的能力在双方同时具有处理安全消息能力时，双方的协商主要经由以下步骤：/ hello_syn ii puk_alice: alice端安全程序发送能力探测报文和alice 的公钥信息；/ hello.syn ii puk_bob: bob端收到探测报文后回复探测响应报文和 bob端公钥信息，同时根据alice的公钥信息和自己的私钥信息计算出会话密钥sk(请参照下一部分opcn-ssl密钥分配中的d-h密钥分配原理); / confm_syn ii esk,na: alice端收到探测响应报文后，根据bob的公 钥信息和自己的私钥信息计算出会话密钥sk,用sk加密随机数na

5、,发 送密钥确认报文；/ confm_ack ii esk,f(na),nb: bob端收到密钥确认报文后，解密出 na并对na进行函数运算(例如na + 1 ),发送确认响应报文和随机数nb;/ confm_ack ii esk,f(nb): alice端收到上述报文，比较收到的f(na) 与本地运算的f(na)的一致性，如果一致则发送确认报文和f(nb),以便 bob端进行确认。以上的5个交互，前2个为探测交互和d-h密钥分配过程；后3个为确认交互和会话密 钥一致性检测过程。如果双方收到的随机数运算和本地随机数运算结果一致，表明会话密钥sk的可用性和 一致性，z后双方的通信报文将通过会话密

6、钥sk进行对称加密传输。当双方只有一方具有处理安全消息能力时，交互图如下:bob不具有安全软件上图给出的是bob端不具有处理安全消息能力吋的吋序图，图上的hello syn ii puk_alicc表示alice端女全程序发出的探测报文，报文包含探测信息和alice的公钥信息。可以看出，安全程序首先对msg命令报文（含有alice发出的文字消息）进行缓存，之 后向bob端发送探测报文并进行计时等待，山于bob端不能处理安全消息，故没有回复报文 存在，当alice端安全程序探测到次数上限时，判定对方不具有处理安全消息的能力，z后 通知alice, bob不支持安全通信。但在上述的交互图中，注意蓝

7、色椭圆所圈点的位置,bob端的msn客八程序直接收到了 alice 端安全程序发送的探测请求报文和alice的公钥信息，客户端会如何处理这种报文，卜面将给出解决方案。前面的文档己经捉到：安全通信能力的判定不应更改msn自身的通信协议与方式，而是要依 赖于msn自身的通信协议与方式进行。由msn协议分析部分我们可以知道：要完成初始协商，我们必须依赖msg命令，应为只有 msg命令的控制域和数据域部分才会被sb服务器直接转发到会话的另一用户。其他的命令 都是以msn通信协议为基础的，它们不能用于我们自己的协商数据的携带。百先分析msg 命令报文的格式，见下表：(表中丨丨标示空格符，对应十六进制 0

8、x20)字段域(field)内容(content)信头域msgiitridiiack_typclllcngthrn控制域版本mime-version: ii verrn消息类型content-type: ii arl;iiarg2;llrn数据域xxxxxxxxxxxxxxxmsg命令报文主要包含信头域、控制域与数据域三部分，采用text/plain格式，功能 为：> 携带键入通知；> 携带应用邀请；> 携带用户消息；针对其小重要的儿个参数说明如下：/ trld事务1d是msn报文中一个非常重要参数,msn利用事务id在tcp 之上再次引入一种确保数据有序的机制。但是通过实验

9、发现，在msn的控制 信令报文中，事务id的失序将会导致服务器或者客户端立刻关闭连接,这多 发生在客户端和ns之间。对于msg报文，对事物id的要求不是十分严格， 事务id失序和重复都不会对msg报文有任何影响，但是该项绝对不可为空。/ ack_type应答类型分为a、n、u三种，u表示不需要服务器应答，n 表示当接受失败时进行应答，a表示成功和失败都需要应答。a很少利用，因 为网络的延时会导致大量重发，一般键入通知与应用邀请采用u类型，携带 有数据域的msg报文采用n类型。/ content-type消息类型表示msg报文的作用，msn中content-type有四 类 ，tex t/p l

10、ain 、 text/x-msmsgscontrol 、 text/x-msmsgsinvite 、application/x-msnmsgrp2p,如果报文中的参数不是这四种，msn 客户端不会 处理该报文，而是直接丢弃。通过上面的分析，我们提出以下方案:/ 用于初始协商的报文采用msg命令携带；/ 为防止一方不具有处理安全消息能力时客户端会直接将协商报文显示为乱码 或者不可理解消息，我们设定协商报文的contenttype格式为 （cxt/x-handshaking（不是4个标准参数之一）；卜面给出协商报文的貝体形式：msg 0 u 80rn 信头域mime-version: 1.0rnc

11、ontent-type: text/x-handshakingrn保证不会被客户端进彳亍消息解析和显示message-type: hello_synrn 消息类型public-key: xxxxxxxxxxxxxxxxrn 公钥信息nn 数据域为空下面是一条正常的msg命令报文，携带的消息为“0k”：msg 276 n 129rnmime-version: 1.0rncontent-type: text/plain; charset=utf-8rnx-mms-im-format: fn=%e5%ae%8b%e4%bd%93; ef=; co=ff; cs=86; pf=2rnrnok通过上述方

12、法处理的协商消息，经过实验证实是不会被客八端处理的。安全程序对对方安全通信能力的判定模块采用状态驱动方法实现,状态机的设置入下图 所示：initial1、收到 hello_syn | puk_b2、发送 hello_ack | puk_a3、计算sk1：收到msg报文，将其缓存2、发速he|xo_syn | puk_a等荐超时1、收到 confm_syn | esk,nb2、发送confm_ack | esk,f(nb),na等待囲时use common modle1.2、3、收到 hellc lack ii puk_b 计算sk发送confia_syn | esk,nawait last ackv/等待超时或者f(na)计 算不一致/等待超时或者f(na) 计算不二kwait confm ack1> 收到 confm_ack | esk,f(na)2、计算的f(na)写收到的f(na)致1> 收到hello_ack | esk,f(na)