专利名称：基于抗抵赖协议的ua与mta间的抗抵赖方法
技术领域：
本发明涉及互联网电子邮件安全技术，特别指一种基于抗抵赖协议(Non-repudationprotocol)的传统电子邮件系统中UA(User Aagent)与MTA(Mail Transfer Agent)间的抗抵赖方法。
背景技术：
作为网络应用系统，电子邮件最早出现在60年代术的ARPANET(早期Internet的主干网)上，由于传递迅速、灵活方便，电子邮件深受用户欢迎，一直是Internet上最繁忙的业务之一。相对于传统邮政业务而言，电子邮件有诸多的优点。但其传输采用的SMTP(Simple Mail Transfer protocol)协议缺少相应的责任归属等安全措施，因此，在垃圾邮件以及邮件仿冒和抵赖等安全问题面前，电子邮件系统无法追究其责任，也就无法有效抵制这种不良行为。
针对邮件系统存在的问题，各种法规纷纷出台。其中就有近期颇受关注的CAN-SPAM反垃圾邮件法规。该法规在2004年1月生效，但调查显示，由于缺乏相应的取证手段，该法规实施以来收效甚微。
Internet已经成为人类社会生活的一部分，电子邮件用户的通信行为也属于社会活动，因此必须承担相应的社会责任。如果邮件系统能够很好的解决邮件传输的责任归属问题，使得发送者和接收者无法否认自己的行为，就能为司法调查提供足够的证据以制裁不法邮件制造者。邮件抗抵赖服务不仅可以解决电子邮件的假冒、垃圾邮件等相关安全问题，还可以促使邮件在电子政务、电子商务领域更广泛，更安全的使用。
在UA与UA间，利用加密、签名技术实现的端到端邮件原始发送者抗抵赖技术，比较典型的有PGP(Pretty Good Privacy)和S/MIME(Secure/Multipurpose Internet MailExtension)。
PGP是Pretty Good Privacy的简称，其特点是对邮件内容进行签名，以保证信件内容无法修改，使用公钥和私钥技术保证邮件内容保密且不可否认。发信人与收信人的公钥都分布在公开的地方，如TFP站点，而公钥本身的权威性则可以由第三方、特别是收信人所熟悉或信任的第三方进行签名认证，没有统一的集中的机构进行公钥/私钥的签发。在PGP系统中，信任是双方之间的直接关系，或是通过第三者、第四者的间接关系，但任意两方之间是对等的。S/MIME是从PEM(Privacy Enhanced Mail)和MIME发展而来的。同PGP一样，S/MIME也利用单向散列算法和公钥与私钥的加密体系。与PGP不同的主要有两点首先，它的认证机制依赖于层次结构的证书认证机构，所有下一级的组织和个人的证书由上一级的组织负责认证，而最上一级的组织(根证书)之间相互认证，整个信任关系基本是树状的。
PGP和S/MIME是端到端的安全电子邮件技术，易于在邮件用户代理上实现，相当的灵活方便。但是存在以下问题邮件传输系统无法强制发送者签名，使得原发抗抵赖只能适用于通信双方事先已经知道对方身份，进行过密钥和证书的交换的情况下。这就破坏了邮件系统原有的“any to any”的优点。
在UA与UA之间引入抗抵赖协议，实现双方不可否认性的技术，最著名的是“可信邮件”。
1981年，M.Blum.在“Three applications of the oblivious transfer”一文中，首次提出了certified mail的概念，将抗抵赖协议引入到邮件系统中。1985年，Even等人利用随机式传输协议(Randomizing protocol)提出的数字挂号函件公平协议。这类协议的特点是不需要第三方便可以防止对方欺骗，实现了双方不可否认性。但这个协议需要双方进行过多的信息交互，以至于在目前的Internet上是无法忍受的；其次这个协议假设通信双方具有相同的计算能力，这个假设在很多实际情况下是不正确的。因此这个协议不具有实用性。
1996年，新加坡ICSD实验室的J.Zhou和伦敦大学的D.Gollman.将可信第三方参与的不可否认协议引入到邮件系统中。2001年霍普金斯大学的Giuseppe Ateniese、MichaelT.Goodrich等人提出了分布式的可信邮件。2002年，Abadi和Glew等提出了一种轻负载可信中心的一种保证电子邮件协议。国外学者设计了多种有可信第三方参与的“可信邮件”协议。但大部分协议都存在TTP负担重，协议交互次数多，效率低，容易造成性能瓶颈等问题。而Micali在2003年提出的“简单快速的公平交换协议”中，采用“不可见”TTP，一定程度上解决了效率问题，但存在一方占优的不公平问题。Ferrer-Gomila提出的FPH协议，及对其改进后的MD协议中，采用三次会话方式，很好的解决了公平性与效率兼顾的问题。
但certified mail仍只适用于双方已有通信约定的情况。
点到点的邮件抗抵赖方案是指在MTA间，或在UA到MTA间的邮件的传输抗抵赖。国内外在电子邮件传输抗抵赖方面的研究成果主要有基于DNS域层次CA的邮件传输代理(MTA)原发抗抵赖方案，以及MASS(Mail Automated Signature Service)。
基于DNS域层次CA的邮件传输代理(MTA)原发抗抵赖方案的思想如下(1)用合法域名标识所有的邮件服务器，使其在DNS中登记。并为这些邮件服务器颁发X509证书。
(2)邮件服务器必须对自己转发的邮件进行内容签名以表示负责。
(3)邮件服务器只转发通过了证书和签名验证的邮件。
该方案有以下优点(1)基于DNS域层次证书信任模型使得MTA证书的合法性可以得到权威的，及时的验证。
(2)在该模型上提出证书验证算法不需要联机的CA参与，易于部署。
IETF的MASS(Mail Automated Signature Service)小组也提出邮件服务器应该为邮件提供自动签名服务。目前这一思想已经转化为较成熟的产品，DomainKEY，以及METASignature。
虽然已经有众多邮件不可否认方面的技术，但现有的技术均没能实现邮件在UA与MTA之间的有责任传递。
作为邮件在网络上传送的第一步，如果能够在发送方客户端与发送方邮件服务器间实现发送方与接收方不可否认性，做到发送者对自己发送的邮件责任，邮件服务器对自己接收的邮件负责，那么，就会在源头上很好的遏制不法邮件的传播。
同样，如果能够在接收方邮件服务器与用户代理之间实现双方不可否认性，就可以很好的解决由抵赖带来的种种纠纷。
发明内容
本发明的技术解决问题是克服现有技术的不足，为传统电子邮件系统中使用SMTP和POP3作为邮件传输协议的UA与MTA间的邮件传输提供双方不可否认服务，以实现UA与MTA之间的强制不可否认性。
本发明的技术解决方案是基于抗抵赖协议的用于传统电子邮件系统中UA与MTA间的抗抵赖方法，其特征在于在邮件传输正常交互的情况下，将NRPUM协议消息封装加入到SMTP协议和POP3协议中，作为SMTP协议和POP3协议命令和应答信息的附带信息进行发送，为传统电子邮件系统中UA与MTA间的邮件传输提供不可否认服务，所述的NRPUM协议消息包括三段会话，分别是正常交互时的交换会话，由于发送方未收到接收不可否认证据发起的取消CANCEL会话，以及接收方未收到发送方的接收应答发起的完成(FINISH)会话，具体过程如下(1)交换会话中发送方首先随机生成临时对称会话密钥，并向接收方发送经过对称会话密钥加密处理的原发不可否认证据；接收方保存原发不可否认证据密文后向发送方发送经过加密处理的接收不可否认证据；发送方解密并验证接收不可否认证据，通过后存储该证据并发送经过加密处理的发送方应答信息，其中包括临时对称会话密钥，表示已收到接收不可否认证据；接收方收到并验证该应答信息后通过后，提取临时对称会话密钥，使用该密钥得到原发不可否认证据，验证该证据通过后将其存储；(2)如果在规定时间内，发送方没有收到接收方的接收不可否认证据或该证据没有通过验证，则发起取消CANCEL会话，向TTP发送仲裁请求，第三方TTP接收仲裁请求后进行仲裁，并将结果分别发送给发送方和接收方；(3)如果在规定时间内，接收方没有收到发送方的发送方应答信息或该信息没有通过验证，或原发不可否认证据没有通过验证，则发起完成FINISH会话，向TTP发送仲裁请求，TTP接收仲裁请求后进行仲裁，并将结果分别发送给发送方和接收方；所述的NRPUM协议在SMTP、POP3中的封装格式为(1)序号域整数，32位长；(2)PCI域，包括若干保留位以及3个标志位EXC、CAN、FIN，初始值均为0。当消息属于交换会话时，EXC位被设置为1；当消息属于取消会话时，CAN被设置为1；当消息属于结束会话时，FIN位被设置为1；(3)SDU域服务数据单元中包含经过加密处理的不可否认证据或发送方应答信息，该域长度可选。
所述的NRPUM协议在SMTP、POP3中的封装方式为(1)SMTP消息序列中发送的邮件体的最后一行为“<CRLF>.<CRLF>”，UA作为发送方将经过加密处理的原发抗抵赖证据封装在UA端发送的“<CRLF>.<CRLF>”之后发送给MTA；MTA作为接收方将经过加密处理的接收不可否认证据封装在MTA端发送的邮件体接收完成应答“250OK”之后发送给UA；UA将经过加密处理的发送方应答信息封装在“QUIT”命令之后发送给MTA；(2)POP3消息序列中，MTA作为发送方将经过加密处理的原发抗抵赖证据封装在对“QUIT”命令的应答“+OK”之后发送给UA；此后，在原POP3消息序列的最后添加两条消息，完成余下的NRPUM协议证据和应答信息发送。
本发明与现有的电子邮件抗抵赖类似技术相比的优点在于以下(1)提出了一种用于传统电子邮件系统的兼顾公平性和传输效率的面向UA-MTA间的双方抗抵赖协议NRPUM。
(2)将该协议加入到传统电子邮件系统中，为UA-MTA间提供了公平、高效的双方抗抵赖服务。
(3)与以往同类技术相比，在保证抗抵赖服务公平性的同时降低了对邮件传输效率的影响。
(4)邮件的抗抵赖和机密性是相互独立的，可以只提供单项服务，也可以与其他服务相结合综合使用。
图1为本发明的抗抵赖协议中参与双方的交互图；图2为本发明的协议消息结构图；图3为本发明实现的系统1层数据流图；图4为本发明的系统发送方程序流程图；图5为本发明的系统接收方程序流程图；图6为本发明实现的TTP Cancel状态仲裁过程数据流图；图7为本发明实现的TTP Finish状态仲裁过程数据流图；图8为本发明实现的TTP仲裁模块的程序流程图；图9为本发明实现的抗抵赖数据单元判断模块数据流图；图10为本发明的协议加入SMTP协议中的交互过程图；图11为本发明的协议加入POP3协议中的交互过程图；其中图1中出现的符号说明A，B，P，Q主体标识，其中A，B标识真实主体，P，Q代表任意主体；T 可信第三方TTP；K 密钥；KAB主体A和B的共享会话密钥；Kp主体P的公钥；Kp-1主体P的私钥；m 主体A发给B的消息；
X，Y 任意消息X，Y按此顺序的串接；H(X) 对消息x使用单向散列函数得到的值；{X)Kp用P的公钥对x加密；{X}Kp-1P用私钥对X加密；{H(X)}Kp-1P用私钥对X加密；P→QX 主体P向Q发送消息x；A 发送者身份标识；L 会话标识，可以是随机值。
图2、5、6中所用数据流院明M1<...@...>邮件发送回溯路径M1’M1，L，SigUA1＝{hash(M1，L)}KA-1R1250OK，SigMTA＝{hash(M1，L)}KB-1M2<...@...>邮件发送前向路径M2’M2，L，SigUA2＝{hash(M2，L)}KA-1R2SigMTA＝{hash(M2，L)}KB-1M3’m-line1；......；m-line n；<CRLF>。<CRLF>， {SigA}KAB={{H(L,m-line1...m-line n,{{KAB}KB}KT)}KA-1}KAB}KB]]>R3{L,SigB={H(L,m-line1...m-line n,{{KAB}KB}KT,{SigA}KAB)}KB-1}KA]]>M5’{L,KAB,SigA′={H(L,KAB)}KA-1}KB]]>Cipher Mail{SigA}KABCTKSA{L，H(m-line1......m-line n)，{{KAB}KB}KT，，{SigA}KAB，，{H(L，H(m-line1..m-linen)，{{KAB}KB}KT，{SigA}KAB)}KA-1}KTCTKSASB{L，H(m-line1......m-line n)，{{KAB}KB}KT，{SigA}KAB，SigB，，{H(L，H(m-line1...m-line n)，{{KAB}KB}KT，{SigA}KAB，SigB，)}KB-1}KTREC C TTPL，CANCELREC C UAL，{H(L，CANCEL，SigB)}KT-1REC C MTAL，{H(L，CANCEL，SigA)}KT-1REC F TTPL，FinishREC F UAL，SigB，{H(L，SigB)}KT-1REC F MTAL，{KAB}KB，{H(L，{KAB}KB)}KT-1
具体实施例方式
本发明将用于UA-MTA间的双方抗抵赖协议NRPUM以一定的封装格式和封装方式加入到邮件传输协议SMTP和POP3的消息序列中，为传统电子邮件系统中使用SMTP和POP3作为邮件传输协议的UA与MTA间的邮件传输提供公平、高效的双方抗抵赖服务。它包括一种兼顾公平性和传输效率的面向UA-MTA间的双方抗抵赖协议NRPUM，及其在传统电子邮件系统中使用时的消息封装格式和方式，与以往同类技术相比，在保证抗抵赖服务公平性的同时降低了对邮件传输效率的影响。
该双方抗抵赖协议NRPUM，协议包括三段会话，如图1所示，分别是正常交互时的交换会话，由于发送方未收到接收不可否认证据发起的取消(CANCEL)会话，以及接收方未收到发送方的接收应答发起的完成(FINISH)会话，具体如下(1)交换会话如图1上部所示，Alice和Bob在正常交互的情况下，需要进行三次交互。发送方Alice首先随机生成临时对称会话密钥KAB，并向接收方Bob发送经过对称会话密钥加密处理的原发不可否认证据{SigA}KAB(该证据包含于消息1)；接收方Bob保存原发不可否认证据密文后向发送方Alice发送经过加密处理的接收不可否认证据{L，SigB}KA(该证据包含于消息2)；发送方Alice解密并验证接收不可否认证据SigB，通过后存储该证据并发送经过加密处理的发送方应答信息，即消息3，其中包括临时对称会话密钥KAB，表示已收到接收不可否认证据；接收方Bob收到并验证该应答信息后通过后，提取临时对称会话密钥KAB，使用该密钥得到原发不可否认证据SigA，验证该证据通过后将其存储。上述过程中不可否认证据均由该证据的发送方利用其私钥签名生成，如SigB＝{H(L，mail，{{KAB}KB}KT，{SigA}KAB)}KB-1，而证据接收方使用证据发送方的公钥对证据进行验证。
(2)如果在规定时间内，发送方Alice没有收到接收方Bob的接收不可否认证据SigB或该证据没有通过验证，则发起取消(CANCEL)会话，如图1中部所示，向TTP发送仲裁请求消息4。TTP接收仲裁请求后进行仲裁，并将结果消息5和6分别发送给发送方Alice和接收方Bob。
(3)如果在规定时间内，接收方Bob没有收到发送方Alice的发送方应答信息消息3或该信息没有通过验证，或原发不可否认证据SigA没有通过验证，则发起完成(FINISH)会话，如图1下部所示，向TTP发送仲裁请求消息7。TTP接收仲裁请求后进行仲裁，并将结果消息8和9分别发送给发送方Alice和Bob。
NRPUM协议在传统电子邮件系统中使用时的消息封装格式，如图2所示，包括(1)序号域整数，32位长。
(2)PCI域(Protocol Control Information协议控制消息)，包括若干保留位以及3个标志位EXC、CAN、FIN，初始值均为0。当消息属于交换会话时，EXC位被设置为1；当消息属于取消会话时，CAN被设置为1；当消息属于结束会话时，FIN位被设置为1。
(3)SDU域(Service Data Unit)服务数据单元中包含经过加密处理的不可否认证据或发送方应答信息，该域长度可选。
NRPUM协议在传统电子邮件系统中使用时的封装方式，如图10、11所示，包括(1)SMTP消息序列中发送的邮件体的最后一行为“<CRLF>.<CRLF>”，UA作为发送方将图1中的消息1封装在UA端发送的“<CRLF>.<CRLF>”之后发送给MTA；MTA作为接收方将图1中的消息2封装在MTA端发送的邮件体接收完成应答“250OK”之后发送给UA；UA将图1中的消息3封装在“QUIT”命令之后发送给MTA。POP3消息序列中，MTA作为发送方将图1中的消息1封装在对“QUIT”命令的应答“+OK”之后发送给UA；此后，在原POP3消息序列的最后添加两条消息，完成余下的图1中的消息2、3的发送。
为实现在上述发明内容，设计一套邮件UA与MTA间双方抗抵赖系统并对其予以实现。
Sendmail是互联网上广泛使用的邮件传输代理软件，Qpopper是互联网上广泛使用的邮件投递软件，有鉴于此，本发明的系统使用Sendmail作为邮件传输代理软件，使用Qpopper作为邮件投递软件。在本发明的实施过程中，使用到了OpenSSL-0.9.7软件包，该软件包所包含的加密库、规范数字证书、数据封装等功能，为系统的实现提供了底层的API，同时使用了Windows SPI编程接口，使本发明能具有更好的适应性。
对UA-MTA间双方抗抵赖系统的设计和实现，遵循以下原则(1)不改变原有电子邮件系统中相关的SMTP和POP3协议、RFC822文本协议和MIME协议；(2)该系统对电子邮件用户来说应该是透明的；(3)邮件的发送方和接收方都进行详细的日志记录，为事后的责任追查和审计提供服务；(4)系统的模块划分尽可能清晰，有较强的可重用性。
根据软件工程的方法，设计了系统数据流图，系统的模块图和系统流程图。
系统1层数据流图如图3所示，图中加工1、3、5、7为发送方主机上执行的加工，加工2、4、6、8、12为接收方主机上执行的加工，加工10、11为TTP上执行的加工。由发送方主机生成M1进入加工Send M1’，加工Send M1’的加工逻辑为向接收方发送M1’并将{SigUA1，M1}流向加工Send M2’。接收方接收到M1’后进入加工Get M1’，加工Get M1’的加工逻辑为向发送方发送R1。加工Send M2’的加工逻辑为向接收方发送M2’并将{SigUA2，M2}流向加工Send mailbody M3’。加工Get M2’的加工逻辑为向发送方发送R2。加工Send mailbody M3’的加工逻辑为生成并向接收方发送M3’，同时生成{CTKSA}和{M3，CKAB，SigUA3}存储在本地，如果接收方应答R3在指定时间内到达并通过数字签名验证，则将{M3，CKAB，SigUA3}流向Send KEY，否则向TTP发送纠纷处理请求{CTKSA}。加工Get M3’的加工逻辑为生成并向发送方发送R3，同时生成{CTKSASB}和Cipher Mail存储在本地，如果发送方应答M5’在指定的时间内到达并通过数字签名验证，则将Cipher Mail流向加工Decrypt，否则向TTP发送纠纷处理请求{CTKSASB}。加工Send KEY的加工逻辑为在发送方接收到接收方发送的R3后向接收方发送M5’，提取并存储R3中的接收方不可否认证据。加工Get KEY的加工逻辑为在接收方接收到发送方发送的M5’后将会话中使用的对称会话密钥KAB流向加工Decrypt。加工Decrypt的加工逻辑为得到KAB和由其加密的密文后，将密文解密并验证，通过后则提取并存储解密出的明文中发送方不可否认证据，同时将邮件存入指定的存储空间Mail box，否则向发送方发送Service closed信息结束会话。
需要特别注意的是在TTP上执行的加工10、11。对于发送方和接收方向TTP发送的纠纷处理请求有处理的时序关系，TTP也因此具有三种不同的状态(1)空闲状态，TTP没有接收到任何一方的请求；(2)Cancel状态，在首先接收到发送方的Cancel请求后TTP所处状态，不论接收方是否发送请求，状态不会改变，直到此次纠纷处理过程结束；(3)Finish状态，在首先接收到接收方的Finish请求后TTP所处状态，不论发送方是否发送请求，状态不会改变，直到此次纠纷处理过程完成结束。
那么，当发送方先于接收方从加工Send mailbody M3’向TTP发送CTKSA时，TTP执行加工Cancel Protocol，此时接收方从加工Get M3’向TTP发送CTKSASB也流向了加工Cancel Protocol。加工Cancel Protocol的加工逻辑为接收发送方和接收方的纠纷处理请求，将TTP置于Cancel状态，向TTP自身、发送方和接收方分别发送纠纷处理结果REC，并将各方对应结果分别存储于各自的结果存储区域。同样，当接收方先于发送方从加工GetM3’向TTP发送CTKSASB时，TTP执行加工Finish Protocol。加工Finish Protocol的加工逻辑为接收发送方和接收方的纠纷处理请求，将TTP置于Finish状态，向TTP自身、发送方和接收方分别发送纠纷处理结果REC，并将各方对应结果分别存储于各自的结果存储区域，与加工Cancel Protocol不同的是，加工Finish Protocol会得到KAB并将其发送给接收方，使接收方能够继续执行加工Decrypt。
本发明实现的系统程序流程图如图4、5所示(1)发送方、接收方和TTP在工作前都已经通过安全方式获得了各自的私钥。
(2)Send()和Receive()函数用于发送和接收NRPUM协议定义的交互信息。
(3)Decrypt()函数用于解密由KAB加密的不可否认证据。
(4)Store()函数用于存储本地临时数据和不可否认证据。
本发明实施的硬件环境选择主要从系统的开发成本考虑，选用Intel X86的计算机作为硬件平台。
在UA上有多种邮件客户端软件可使用，虽然都基于邮件传输的RFC标准，但其实现各不相同。为了能够更广泛的使用本发明，使其与特定的邮件客户端软件无关，选用Windows SPI编程接口实现本发明在UA上的功能。
MTA软件的选择Sendmail和Qpopper是使用很广泛的电子报文传输代理软件和电子邮件投递软件，且上述两款软件均为开放源码的软件，因此选择Sendmail和Qpopper作为MTA上的传输和投递软件。
操作系统的选择选择Solaris。Unix的一种，非常稳定。
开发工具的选择核心方法的实现选用符合标准ANIS C的gcc(GUN C)作为开发语言，系统的开发使用OpenSSL-0.9.7和Windows SPI。
TTP仲裁模块的数据流图如图6、7所示，该模块的功能是接收并处理由UA或MTA发送到TTP的纠纷处理请求。如果TTP首先接收到发送方的Cancel请求，如图6所示，则由加工TTP Cancel session将TTP置于Cancel状态下，并生成REC C TTP存储到TTPREC C中，同时生成TTP的仲裁信息分别流向加工Store UA REC C和Store MTA REC C。由加工Store UA REC C和Store MTA REC C将对应的仲裁信息分别存储于发送方和接收方的仲裁信息记录空间。同样，如果TTP首先接收到接收方的Finish请求，如图7所示，则由加工TTP Finish session将TTP置于Finish状态下，并生成REC F TTP存储到TTPREC F中，同时生成TTP的仲裁信息分别流向加工Store UA REC F和Store MTA REC F。由加工Store UA REC F和Store MTA REC F将对应的仲裁信息分别存储于发送方和接收方的仲裁信息记录空间，并向接收方提供会话密钥KAB。
TTP仲裁模块的数据流程图如图8所示(1)在TTP进入仲裁过程之前，已通过安全方式获得了TTP自身的私钥。
(2)TTP对所接收的请求进行判断，如果是发送方的Cancel请求，则执行cancel功能；如果是接收方的Finish请求，则执行finish功能。
(3)在执行cancel功能的过程中，如果发现原TTP状态为空闲NULL，则将TTP置于Cancel状态下，并执行相应处理程序；如果发现原TTP状态为Finish，即TTP首先接收到了接收方的Finish请求，则执行Finish状态下的处理过程。
(4)在执行finish功能的过程中，如果发现原TTP状态为空闲NULL，则将TTP置于Finish状态下，并执行相应处理程序；如果发现原TTP状态为Cancel，即TTP首先接收到了发送方的Cancel请求，则执行Cancel状态下的处理过程。
抗抵赖数据单元判断模块的数据流程图如图9所示，发送方和接收方每次接收到对方的消息都会调用该模块，其功能为判断消息中是否包括抗抵赖数据单元，如果包括，则将抗抵赖数据单元取出按照系统定义的方式进行相应处理，并存储不可否认证据。如果不包括，则将消息传给客户端软件或服务器软件进行相应处理。
以上实现，仅为本发明的较佳实现而已，并非用于限定本发明的保护范围。
权利要求
1.基于抗抵赖协议的UA与MTA间的抗抵赖方法，其特征在于在邮件传输正常交互的情况下，将NRPUM协议消息封装加入到SMTP协议和POP3协议中，作为SMTP协议和POP3协议命令和应答信息的附带信息进行发送，为传统电子邮件系统中UA与MTA间的邮件传输提供不可否认服务，所述的NRPUM协议消息包括三段会话，分别是正常交互时的交换会话，由于发送方未收到接收不可否认证据发起的取消CANCEL会话，以及接收方未收到发送方的接收应答发起的完成(FINISH)会话，具体过程如下(1)交换会话中发送方首先随机生成临时对称会话密钥，并向接收方发送经过对称会话密钥加密处理的原发不可否认证据；接收方保存原发不可否认证据密文后向发送方发送经过加密处理的接收不可否认证据；发送方解密并验证接收不可否认证据，通过后存储该证据并发送经过加密处理的发送方应答信息，其中包括临时对称会话密钥，表示已收到接收不可否认证据；接收方收到并验证该应答信息后通过后，提取临时对称会话密钥，使用该密钥得到原发不可否认证据，验证该证据通过后将其存储；(2)如果在规定时间内，发送方没有收到接收方的接收不可否认证据或该证据没有通过验证，则发起取消CANCEL会话，向TTP发送仲裁请求，第三方TTP接收仲裁请求后进行仲裁，并将结果分别发送给发送方和接收方；(3)如果在规定时间内，接收方没有收到发送方的发送方应答信息或该信息没有通过验证，或原发不可否认证据没有通过验证，则发起完成FINISH会话，向TTP发送仲裁请求，TTP接收仲裁请求后进行仲裁，并将结果分别发送给发送方和接收方；
2.根据权利要求1所述的基于抗抵赖协议的UA与MTA间的抗抵赖方法，其特征在于所述的NRPUM协议在SMTP、POP3中的封装格式为(1)序号域整数，32位长；(2)PCI域，包括若干保留位以及3个标志位EXC、CAN、FIN，初始值均为0。当消息属于交换会话时，EXC位被设置为1；当消息属于取消会话时，CAN被设置为1；当消息属于结束会话时，FIN位被设置为1；(3)SDU域服务数据单元中包含经过加密处理的不可否认证据或发送方应答信息，该域长度可选。
3.根据权利要求1所述的基于抗抵赖协议的UA与MTA间的抗抵赖方法，其特征在于所述的NRPUM协议在SMTP、POP3中的封装方式为(1)SMTP消息序列中发送的邮件体的最后一行为“<CRLF>.<CRLF>”，UA作为发送方将经过加密处理的原发抗抵赖证据封装在UA端发送的“<CRLF>.<CRLF>”之后发送给MTA；MTA作为接收方将经过加密处理的接收不可否认证据封装在MTA端发送的邮件体接收完成应答“250 OK”之后发送给UA；UA将经过加密处理的发送方应答信息封装在“QUIT”命令之后发送给MTA；(2)POP3消息序列中，MTA作为发送方将经过加密处理的原发抗抵赖证据封装在对“QUIT”命令的应答“+OK”之后发送给UA；此后，在原POP3消息序列的最后添加两条消息，完成余下的NRPUM协议证据和应答信息发送。
全文摘要
基于抗抵赖协议的UA与MTA间的抗抵赖方法，包括如下内容一种用于传统电子邮件系统的兼顾公平性和传输效率的面向UA－MTA间的双方抗抵赖协议NRPUM，及其使用时的消息封装格式和方式。在不影响邮件传输正常交互的情况下，将NRPUM协议消息封装加入到SMTP协议和POP3协议中，作为SMTP协议和POP3协议命令和应答信息的附带信息进行发送，为传统电子邮件系统中UA与MTA间的邮件传输提供不可否认服务。邮件发送方和接收方分别从各自接收到的命令和应答信息中提取附带信息，再从附带信息中提取不可否认证据，最后存储不可否认证据；如在其中出现NRPUM协议交互异常，发送方和接收方则分别向Offline－TTP发送纠纷处理请求，由TTP作出仲裁并向各方发送请求处理结果，发送方、接收方和TTP均存储各自处理结果。
文档编号H04L29/06GK1852316SQ20061001163
公开日2006年10月25日 申请日期2006年4月10日 优先权日2006年4月10日
发明者夏春和, 李肖坚, 刘璀 申请人:北京航空航天大学