CN101821987B - 有效认证电子邮件协议 - Google Patents

有效认证电子邮件协议 Download PDF

Info

Publication number
CN101821987B
CN101821987B CN200880111327.9A CN200880111327A CN101821987B CN 101821987 B CN101821987 B CN 101821987B CN 200880111327 A CN200880111327 A CN 200880111327A CN 101821987 B CN101821987 B CN 101821987B
Authority
CN
China
Prior art keywords
message
recipient
protocol
transmit leg
party
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN200880111327.9A
Other languages
English (en)
Other versions
CN101821987A (zh
Inventor
J·邵
B·朱
M·冯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CN101821987A publication Critical patent/CN101821987A/zh
Application granted granted Critical
Publication of CN101821987B publication Critical patent/CN101821987B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种用于双方事务的示例性乐观协议包括设置子协议、交换子协议、以及争端子协议，设置子协议包括授权的Diffie-Hellman密钥协定，交换子协议包括将证书从发送方发送到接收方并将收条从接收方发送到发送方，而争端子协议包括用于解决发送方和接收方之间的由于发送无效证书、由于发送无效收条或由于中止交换子协议而引起的争端的争端解决机制。还公开了其它示例性方法、系统等。

Description

有效认证电子邮件协议
背景
在邮递世界中，当挂号信到达时，当且仅当人们签署证明接收到这封信的确认时，这封信才被正式接收。在该示例中，两个动作(即签署确认和接收信件)同时发生。在电子连接的世界中，广泛地使用电子邮件(即“email”)。由于方便且快速递送以及文档化(例如已发送邮件箱)，比起传统递送邮件来说，大多数人在与其他人通信时偏爱电子邮件。为了使电子邮件同等于常规邮递，电子邮件系统应包括提供与挂号信相同的保证的某种类型的功能。具体而言，这一功能应要求电子邮件的收件人在能阅读挂号电子邮件之前签署接收确认。
与挂号信的邮递世界相反，对于电子邮件系统，由于电子邮件系统的分布式特性：电子邮件系统中所使用的协议本质上是异步的，两个动作(即签署和接收)无法同时发生。
存在可在分布式环境中提供“挂号信”的某些服务。例如，也被称为不可抵赖协议的所谓的认证电子邮件协议(certified email protocol)可提供通过诸如因特网等网络的两个不可信方之间的公平消息交换和不可否认的接收。
除了认证电子邮件之外，认证电子邮件协议还可用于许多其他应用。一个应用是保护移动主体的路线，其中当移动主体从一个主机传递至另一个时在这两个相邻主机之间应用认证电子邮件协议。在该上下文中，如果移动主体的路线被更改，则可使用由认证电子邮件协议提供的不可否认的消息和收条来标识攻击源。可从认证事务协议中受益的其它应用包括鼓励人们共享或传播诸如自己创作的影片或广告等内容的应用，其中认证电子邮件协议可帮助确保共享内容的用户通过兑现来自接收内容的用户的收条来获得报酬。
密码研究团体已经广泛地研究了认证电子邮件协议。认证电子邮件协议解决了实质上属于由所谓的“公平交换协议”解决的问题的子集的问题，其中经交换的项目不必限于如认证电子邮件协议中的消息和收条(即除电子邮件之外的数字项目可使用该公平交换协议来交换)。例如，双方都可交换由公平交换协议中的每一个单独方签署的签名。
取决于可信第三方(TTP)的可用性和设置，可将公平交换归类为以下四种类型：(1)不具有TTP、(2)具有内联TTP、(3)具有在线TTP、以及(4)具有离线TTP。对于公平交换的第一种类型，早在1980年，研究表明不可能在确定性的双方公平交换协议中实现公平。现有协议只可提供部分公平性：计算公平性或概率公平性。然而，这些协议往往太复杂且低效以至于无法适用于实际应用(例如分布式的基于web的应用)。对于公平交换的第二种类型，TTP担当发送者和接收者之间的中介，并且整个消息通过TTP来发送。内联TTP可提供完整的公平性，因为所有经交换的消息完全由TTP控制。然而，TTP可成为性能瓶颈，尤其是在必须同时转发许多大型消息时。对于第三种类型，即类似于内联TTP的在线TTP，必须对于整个交换生存期可用。在这一设置中，TTP无需转发整个消息。TTP只处理和转发诸如密钥等信令信息。对于也被称为乐观协议的公平交换的最后一种类型，只在一方表现恶意或者通信信道在执行交换协议期间中断的情况下才涉及TTP。该特性在包括上述分布式环境(例如分布式的基于web的环境)的许多应用中是实际的。
除了专用的认证电子邮件协议之外，还存在各种通用的认证电子邮件协议，其中使用通用加密和签名原语。这些通用的认证电子邮件协议通常利用以下方法：(i)通过对称加密方案来加密消息、(ii)通过公钥加密方案用TTP的公钥来加密对称加密中所使用的密钥、以及(iii)通过签名方案用发送者的私钥来签署所得密码。在这一方案中，当接收者接收到签名时，该接收者首先检查接收到的签名的有效性。如果签名有效，则接收者向发送者发送收条以指示该接收者已接收到消息。该接收者的利益得到保护，因为如果发送者拒绝揭示所交换的消息，则TTP可为接收者揭示该消息。
总而言之，离线TTP方法具有优点，但到至今为止，离线TTP认证电子邮件协议缺乏效率。如此处所描述的，各种示例性技术可提高离线TTP认证协议的效率。这些技术可以在电子邮件和/或在分布式环境中发生的其他事务的上下文中实现。
概述
一种用于双方事务的示例性乐观协议包括设置子协议、交换子协议以及争端子协议，设置子协议包括授权的Diffie-Hellman密钥协定，交换子协议包括将证书从发送方发送到接收方并将收条从接收方发送到发送方，而争端子协议包括用于解决发送方和接收方之间的由于发送无效证书、由于发送无效收条或由于中止交换子协议而引起的争端的争端解决机制。还公开了其它示例性方法、系统等。
附图说明
参考以下附图描述非限制性和非穷尽的示例：
图1是用于分布式应用环境中的事务的示例性系统的图示；
图2是示例性协议以及供该协议使用的示例性签名方案的框图；
图3是用于涉及离线第三方的争端解决的示例性方法的框图；
图4是用于密钥生成的示例性方法的框图；
图5是用于事务中的发送者的示例性方法的框图；
图6是用于事务中的接收者的示例性方法的框图；
图7是供第三方处理事务中的争端的示例性方法的框图；
图8是能在事务中引发争端的示例性情形的框图；
图9是涉及恶意接收者的示例性争端情形的框图；
图10是涉及恶意发送者的示例性争端情形的框图；以及
图11是示例性计算设备的框图。
详细描述
各种示例性技术实现公平交换协议中的授权密钥协定。也被称为不可抵赖协议的认证电子邮件协议允许按以下公平的方式交换消息用于对接收的确认：发送者Alice当且仅当Alice接收到来自接收者Bob的收条的情况下向Bob发送消息。如将在以下更详细地描述的那样，一种示例性方法应用授权的Diffie-Hellman密钥协定协议来构造认证电子邮件协议。这一示例性方法产生只在某一方欺诈或例如通信信道在交换期间中断时涉及离线可信第三方的乐观认证电子邮件协议。
来自与其它乐观认证电子邮件协议的对比试验的信息表明具有授权密钥协定的示例性认证电子邮件协议是最有效的乐观认证电子邮件协议。
此处所描述的示例性协议是具有离线TTP的认证电子邮件协议。这一示例性协议可允许在认证电子邮件协议的上下文中加密消息。与使用离线TTP的公钥来加密随机选择的消息加密密钥以使得TTP能够提取消息加密密要以便在执行争端协议时揭示消息的具有离线TTP的其它认证电子邮件协议相反，一种示例性协议用在发送者和TTP之间共享的密钥来加密消息，但在交换期间不涉及TTP。在这一示例性方法中，不需要应用公钥加密方案来加密消息加密密钥的常规步骤，这导致更有效的协议。
图1示出了示例性系统100以及时间线103。系统100包括作为消息发送者(发送方)的用户A 110、作为消息接收者(接收方)的用户B 120、用于处理争端的离线可信第三方(TTP)130、以及用于发放证书的认证机构(CA)140。各方110、120、130和140分别具有相关联的计算设备113、123、133和143，这些计算设备包括到网络150的通信链接。各种密钥在图1中示出，其中私钥连同关联指示符(例如A、CA、T)被标记为142，而公钥连同关联指示符(例如A、CA、T)被标记为144。
示例性时间线103示出一系列事件，这些事件可根据协议的各部分(例如子协议)和事务中所涉及的各阶段来分类。例如，在涉及密钥生成的初始化阶段期间，TTP 130选择私钥142(私钥T)并计算公钥144(公钥T)，而用户A 110选择私钥142(私钥A)并计算公钥144(公钥A)并且向CA 140注册密钥144以获取将用户A 110与用户A的公钥144(公钥A)绑定的证书145。
在消息准备和发送阶段，用户A 110加密消息115并向用户B 120发送经加密的消息117和包括消息描述和证书145的信息。
在接收阶段，用户B 120检查用户A 110的证书145并执行对接收到的所述信息的另一检查。如果两个检查都通过，则用户B 120向用户A 110发送签名125。
在确认阶段，用户A 110从用户B接收签名125并检查签名125以查看其是否有效。如果签名125有效，则用户A 110向用户B 120发送用于解密经加密的消息117的信息。
在解密阶段，用户B 120从用户A 110接收所述信息并解密经加密的消息117。然而，如果用户B 120(i)未接收到所述信息或者(ii)已解密的消息不匹配先前接收到的消息描述，则用户B 120可调用争端协议(例如争端解决阶段)。
一种示例性协议结合授权的Diffie-Hellman密钥协定来操作以便在发送者和TTP之间共享消息加密密钥。这一示例性协议是公平且乐观的并且表现出以下特性：
公平性：如同其它认证电子邮件协议那样，该示例性协议保证公平性，即，恶意方无法在交换消息和收条时获得胜于另一方的任何优势；
乐观主义：只在一方实施恶意行为或者通信信道在交换期间中断时才涉及TTP，这使该协议乐观；TTP的无状态性：TTP无需在执行协议期间存储任何状态信息，例如，无需任何状态信息来处理双方之间的争端；以及
高性能：该示例性协议在性能测试中表现出与其它被测认证电子邮件协议相比最小的计算和通信成本。
一种示例性协议还可包括用于处理适时终止的细微问题的特征。在各种示例中，解决消息的机密性，其中为获得公平性，加密消息“m”。在一示例性交换中，事务涉及所交换的消息“m”和消息“m”的签名。
图2将示例性协议200示为包括设置子协议210、交换子协议220和争端子协议230。图2还示出了供协议200使用的示例性签名方案250。在图2的示例中，签名方案250是经修改的Schnorr签名方案。签名方案250包括设置算法252、签署算法254和验证算法256。在图2的示例中，签名方案250证明对于随机谕示模型中利用离散对数假设的自适应选择的消息攻击来说是安全的。
设置算法252取安全参数1k作为输入，并输出公钥(G，q，g，H(·)，y)和密钥x，其中q是大素数，G是具有q阶的生成函数g的有限循环群，H(·)是密码散列函数：且y＝gx∈G。M是消息域。
签署算法254通过应用以下操作来签署消息m∈M：(1)选择随机数
Figure GPA00001094699100052
，(2)计算R＝gr∈G，以及(3)将签名设为σ＝(R，s)，其中s＝r+xH(m||R||y)modq。
验证算法256验证签名。例如，为了验证消息m的签名σ，验证器检查。如果等式成立，则签名有效且输出b＝1；否则，签名无效且算法输出b＝0。
图3示出了用于争端解决的示例性方法300。方法300包括各种双方事务步骤以及使用离线可信第三方(TTP)的第三方争端解决机制。在步骤304，用户A(发送方)向用户B(接收方)发送加密消息和证书。在步骤308，用户B接收加密消息和证书。判定框312为用户B判断从用户A接收到的证书是否有效。如果判定框判断证书无效，则方法300在报告步骤314中向离线TTP报告以解决该问题。然而，如果判定框312判断证书有效，则方法300在步骤316处继续，用户B向发送者用户A发送签名(例如收条)。
响应于接收到签名，在步骤320，用户A向用户B发送用于解密该消息的信息。判定框324判断用户B是否接收到用于解密该消息的信息。如果判定框324判断出用户B未接收到该信息，则方法300按照步骤314那样向离线TTP报告；否则方法300在另一判定框328处继续，该判定框328判断接收到的信息是否匹配或对应于先前接收到的经加密的消息(参见步骤308)。如果该信息不匹配或不对应，则方法300在步骤314处向TTP报告；否则，方法300继续至步骤322，将从用户A到用户B的传输确认为成功(例如“好的”)。
根据方法300，从发送方(用户A)到接收方(用户B)的消息(例如经加密的消息)传输作为双方事务发生，并且仅在引发问题的情况下才涉及第三方(TTP)。因此，方法300提供具有第三方监督和争端解决保证的有效传输。
如以上参考图2已经提到的那样，示例性认证电子邮件协议200包括三个子协议：设置子协议210、交换子协议220、以及争端子协议230。例如，在图1中，假设用户A 110是Alice(发送者/发送方)，用户B 120是Bob(接收者/接收方)，而TTP 130是Charlie。还假设认证机构(CA)140的公钥144(公钥CA)和三方对每一个方都是已知的。令m表示已发送消息115(或在加密时表示经加密的消息117)并且令σB表示收条(即来自用户B 120(即Bob)的签名125)。
给定上述条件，子协议210可选择系统参数(q，G，g)，其中q是大素数，且G是具有q阶生成函数g的区间Diffie-Hellman(gap Diffie-Hellman：GDH)群。于是Charlie 130选择他的随机私钥142(私钥_T)
Figure GPA00001094699100071
，并且计算和公开对应的公钥144(公钥_T)
Figure GPA00001094699100072
Alice 110也选择她的随机私钥142(私钥_A)
Figure GPA00001094699100073
，并且计算对应的公钥144(公钥_A)。但是，她向CA 140注册她的公钥144(公钥_A)和她的系统参数以获取将她的身份IDA与对应的公钥144(公钥_CA)绑定的她的证书145CA(q，G，g，ya)。
根据该示例，如果能够在多项式时间中对以下第一个问题求解但没有p.p.t.算法能够以胜于多项式时间中的随机猜测的不可忽略的优点对以下第二个问题求解，则具有素数q阶生成函数g的有限循环群G是区间Diffie-Hellman(GDH)群。同样，判决性Diffie-Hellman(Decisional Diffie-Hellman)问题可被表征为：给定(g，ga，gb，gc)∈G*G*G*G，判断
Figure GPA00001094699100075
是否成立，其中a、b、c是Zq *中的三个随机数。在该问题中，如果，则(g，ga，gb，gc)是判决性Diffie-Hellman(DHH)元组。给定(g，ga，gb)∈G*G*G，表征计算性Diffie-Hellman(computational Diffie-Hellman)问题以计算gab∈G，其中a、b是Zq *中的两个随机数。
对于交换子协议220，Alice 110向Bob 120发送具有在该示例中被称为消息描述Dscm的消息信息的消息115m(或在加密时为经加密的消息117C)，并且Alice 110从Bob 120接收收条125(例如签名)。消息描述Dscm可被配置成使得用户能够验证消息。例如，简单的描述是消息的散列值。实际描述可取决于使用该协议的应用。当在鼓励共享多媒体的应用中使用时，Dscm可以是诸如标题、作者等多媒体内容的描述。注意，一把而言，描述Dscm的知识不揭露其消息m。
在子协议220中，消息描述Dscm用于检查已解密的消息是否匹配其描述。在以下描述中，(Ek(·)，Dk(·))是具有加密密钥k的对称加密和解密操作对。H(·)、H1(·)和H2(·)是密码散列函数。子协议220可根据以下示例来进行：
I.Alice 110首先选择随机数
Figure GPA00001094699100077
，并计算
R1＝gr∈G，
Figure GPA00001094699100078
R′＝H(R2)，k＝H1(R2)，
C＝Ek(m)，sA＝r+xaH2(C||Dscm||IDA||IDB||IDC||R1||R′||ya)modq.
Alice 110然后向Bob 120发送信息(CA，R1，R′，C，Dscm，sA)，其中证书145CA是用设置子协议210获取的Alice的证书。
II.在接收到来自Alice 110的信息(CA，R1，R′，C，Dscm，sA)时，Bob 120首先确认Alice的证书145，并且然后检查以下等式是否成立，
g s A = ? R 1 y a H 2 ( C | | Dsc m | | ID A | | ID B | | ID C | | R 1 | | R ′ | | y a ) ∈ G .
如果两个检查都通过，则Bob120将其签名125(R1，R′，C，Dscm，sA，DIA，IDB，IDC)上的σB发送到Alice 110。
III.在接收到来自Bob 120的签名125σB时，Alice 110首先确认Bob的签名125σB。如果对签名125的确认成功，则Alice 110向Bob 120发送参数R2。
IV.在接收到参数R2时，Bob 120计算密钥k＝H1(R2)并且使用该密钥来解密先前接收到的经加密的消息117C以获取所想要的消息
Figure GPA00001094699100082
。当且仅当m的确匹配先前接收到的消息描述Dscm时，已解密的消息115m被认为有效。如果Bob 120未接收到参数R2，或R′≠H(R2)，或者已解密的消息115m不匹配其描述Dscm，则Bob 120可调用争端协议230。
参数R1可用作争端子协议230中的Diffie-Hellman密钥协定中的密钥资料的一部分；参数R2是Diffie-Hellman密钥协定的所得密钥。集合(R1，sA)是对应于通过使用经修改的Schnorr签名方案而获取的公钥ya的(C，R′，Dscm，IDA，IDB，IDC)上的签名。注意，在上述项目II中，Bob的签名125σB可以是任何合适类型的签名。
Alice 110可将她从Bob 120接收到的签名125σB用作收条以便根据以下过程来向另一个人(例如John)证明Bob 120已从她接收到消息115m：
1.Alice向John发送(σB，R1，R′，C，Dscm，sA，CA，IDB，IDC，m，R2)
2.John检查以下各项是否成立：
i.m与Dscm一致，
ii.σB、sA、CA有效，
iii. C = E H 1 ( R 2 ) ( m ) ,
iv.R′＝H(R2)，并且
v.(g，R1，yc，R2)是判决性Diffie-Hellman(DDH)元组。在该示例中，如果上述所有检查都通过，则没有一方(non-party)实体(例如John)相信Bob 120的确已从Alice 110接收到消息115m。
在各示例中，示例性协议使用区间Diffie-Hellman群。在这些示例中，Alice110可通过使用诸如配对等某些特殊算法来确定(g，R1，yc，R2)是否是DDH元组。在某些应用中，Alice 110可能只需向TTP 130证明Bob 120已接收到消息125m(例如在John是TTP的情况下)。在这种情况下，该协议与上述相同，除了可以用其CDH问题在计算上是困难的(注意，区间Diffie-Hellman群始终是CDH困难群但反之并非亦然)的有限循环群来替换区间Diffie-Hellman群，并且不必使用诸如配对之类的区间Diffie-Hellman群的算法来解决DDH问题。因为TTP 130已经知道其自己的密钥142(私钥T)xc，所以TTP 130可通过检查
Figure GPA00001094699100091
是否成立来确定(g，R1，yc，R2)是否是DDH元组。
对于争端子协议230，如果Bob 120已将其签名125σB发送到Alice 110但还没有接收到参数R2，或者从Alice 110接收到的参数R2无效，则Bob 120可调用争端子协议230并向TTP Charlie 130发送信息(CA，R1，R′，C，Dscm，IDA，IDB，IDC，sA，σB)(例如有时也被称为信息向量)。对于被认为无效的接收到的参数R2，如果已解密的消息115m不匹配其描述Dscm，或者R′≠H(R2)，则参数R2可被认为是无效的。在接收到来自Bob 120的数据(例如所述向量)时，TTP Charlie 130可执行以下操作：
1.Charlie 130首先确认接收到的数据。该步骤可以与交换子协议220中的数据确认步骤相同。如果确认失败，则Charlie 130中止。否则，Charlie 130继续。
2.Charlie 130计算参数
Figure GPA00001094699100092
，并应用解密操作来获取消息
Figure GPA00001094699100093
Figure GPA00001094699100094
。如果消息115m的确匹配其描述Dscm且R′＝H(R2)，则Charlie130向Bob 120发送参数R2并向Alice 110发送签名125σB。
如果消息125m的确匹配其描述Dscm或R′≠H(R2)，则Alice 110无法将Bob的签名125用作收条以便向其他人证明Bob 120已从她接收到消息115m，因为所述数据确认将失败(参见例如上述的确认测试)。
如此处所描述的，一种用于双方事务的示例性乐观协议包括设置子协议、交换子协议、以及争端子协议，设置子协议包括经授权的Diffie-Hellman密钥协定，交换子协议包括将证书从发送方发送到接收方并将收条从接收方发送到发送方，而争端子协议包括用于解决发送方和接收方之间的由于发送无效证书、由于发送无效收条或由于中止交换子协议而引起的争端的争端解决机制。对于后者，交换子协议可出于包括一方的动作、硬件故障、软件故障、传输失败等在内的各种原因中的任一种而中止。在这一协议中，事务可以是电子邮件事务。在这一协议中，交换子协议可包括发送经加密的消息和证书。
示例性交换子协议可包括将解密信息从发送方发送到接收方以解密先前从发送方发送到接收方的信息。示例性交换子协议可包括将信息从发送方发送到接收方以及将该信息与先前从发送方发送到接收方的信息进行比较。在这一子协议中，不利的比较可调用争端子协议，例如，涉及可信第三方(例如通常是对于双方事务来说的离线方)的争端子协议。
一示例性协议包括授权的Diffie-Hellman密钥协定，该密钥协定包括在发送方和可信第三方(例如通常是对于双方事务来说的离线方)之间共享加密密钥。
在各示例性乐观协议中，发送方和接收方经由在分布式计算环境中操作的分布式应用(例如基于web的应用)来交易。
一示例性设置子协议包括将发送方的公钥绑定到用于该发送方的证书。这一子协议可包括用于为接收方生成随后可被发送到另一方的签名的经修改的Schnorr签名方案。
图4、5、6和7呈现了示例性方法400、500、600和700，这些方法分别涉及密钥生成、发送者动作(例如发送方的动作)、接收者动作(例如接收方的动作)以及争端动作(例如涉及离线可信方的动作)。
图4示出了用于密钥生成的示例性方法400的框图。在选择框404中，可信方(TTP)选择私钥。接着，在计算框408中，可信方计算公钥。在另一选择框412中，发送者选择私钥并且在计算框416中，发送者计算公钥。之后是注册框420，发送者向一机构注册其公钥。作为响应，经由发送框424，该机构向发送者发送证书以将该发送者绑定到该发送者的公钥。
图5示出了用于发送者的示例性方法500的框图。在获取框504中，发送者(例如发送方)从机构获取证书。例如，如方法400所解释的，发送者可从机构获取将该发送者与该发送者的公钥绑定的证书。在撰写框508，发送者撰写消息。接着，在加密框512中，发送者加密消息，这可以是取决于应用和/或环境(例如一个或多个接收方、通信链路等)的可选动作。在图5的示例中，在加密后，在发送框516中，发送者发送消息以及(i)消息描述和(ii)证书。
在图5的示例中，将经加密的消息、消息描述和证书发送给接收者。然而，作为替换解决方案，可发送消息描述和证书而不发送消息。例如，在未加密消息但需要可信方争端机制的情况下，可以在发送者接收到来自接收者的收条或签名之后的某一时刻发送消息。
一般而言，发送者将发送经加密的消息和关于消息的某些信息以及证书，接收者将发送收条，并且如果收条有效，则发送者将发送用于解密经加密的消息的信息，其中接收者可对照先前接收到的信息来检查已解密的消息。
一种示例性方法包括向认证机构提供公钥，从认证机构接收绑定该公钥的证书，将经加密的消息和证书发送到接收方，从接收方接收签名，以及响应于该接收，向接收方发送用于解密消息的信息。这一方法可包括将消息描述与经加密的消息一起发送。
图6示出了用于接收者的示例性方法600的框图。在接收框604中，接收者(例如，接收方)接收经加密的消息以及(i)消息描述和(ii)证书。在检查框608中，接收者检查描述和证书。例如，接收者可检查证书以查看该证书是否有效。发送框612假设按照检查框608的检查是成功(即通过)的，并向消息发送者发送签名。在图6的示例中，在接收者采取任何进一步动作之前，发送者必需按照确认和发送框616来行动。在发送者框616中，发送者确认接收者的签名并且然后向接收者发送信息，其中该信息涉及消息的加密。在接收和解密框620中，接收者接收解密信息并解密消息。
一种示例性方法包括生成签名，从发送方接收经加密的消息和证书，向发送方发送签名，从发送方接收用于解密消息的信息，以及解密消息。这一方法可包括使用经修改的Schnorr签名方案来生成签名。在这一示例性方法中，接收方可以在解密之前从发送方接收消息描述，然后将已解密的消息与消息描述进行比较。例如，该描述可包括可以与已解密的消息中的信息进行比较的信息。如果比较是有利的，则无需采取任何进一步动作。然而，如果比较是不利的，则接收方可以与可信第三方一起解决该争端。
如已经参考图3所解释的那样，争端可能在发送者和/或接收者采取或省略动作时的各个时刻引发。另外，故障信息可引发争端。此外，设备和/或软件故障可引发争端。一般而言，出于各种原因中的任一种的交换协议的中止可引发争端。例如，在传输失败期间，发送方或接收方可调用争端机制(例如为了确保正确的事务，为了通知事务出现问题，为了提供诊断信息等)。
图7示出了用于第三方的示例性方法700的框图。在图7的示例中，第三方通过实现与发送者和/或接收者要求密切合作的一个或多个争端机制来处理争端。例如，要求包括(i)发送者必须获取证书以及(ii)接收者必须发送收条(例如签名)，其中(iii)接收者可确认证书以及(iv)发送者可确认签名。另外，如上所述，发送者可向接收者发送诸如消息描述等信息，接收者稍后可对照接收到的消息和/或已解密的消息来检查该信息。
在方法700中，按照调用框704，接收者调用争端子协议，注意，事务的任一方都可调用该争端子协议。在各示例中，事务涉及将消息从第一方(例如发送方)发送到第二方(例如接收方)。如此处所描述的，其它类型的事务是可能的并且这些事务的各方都可调用这一争端子协议，假设满足如上所述(例如i-iv)的某些基本要求。
在确认框708中，第三方确认接收者所接收到的数据(例如信息)(例如证书、消息描述、收条等)。接着，在计算和解密框712中，第三方计算参数(例如参数R2)并且然后执行解密操作以解密发送者已经发送到接收者的经加密的消息。随着在消息被解密，按照判定框716，第三方判断已解密的消息是否匹配接收者所提供的描述(例如从发送者接收到的)。如果判定框716判断消息不匹配描述，则按照结论框720，方法700得出发送者无法证明接收者已接收到消息的结论。然而，如果判定框716判断消息匹配描述，则按照发送框724，第三方向接收者发送参数(例如参数R2)并将接收者的签名或收条发送到发送者。
示例性认证事务协议(例如图2的协议200)的安全性可如下分析。经修改的Schnorr签名方案对于在随机谕示模型中利用离散对数(DL)假设的自适应选择的消息攻击和公钥替换攻击来说是安全的。考虑一证据，与原始Schnorr签名方案相比，经修改的Schnorr签名方案的唯一区别是H(m||R||y)而非H(m||R)。然而，在随机谕示模型中，两个散列谕示都可选择用相同的输出来响应对输入(m，R，y)上的H(m||R||y)的查询以及对输入(m，R)上的H(m||R)的查询。因为Schnorr签名方案被证明对于在随机谕示模型中利用DL假设的自适应选择的消息攻击来说是安全的，所以可得出经修改的Schnorr签名方案对于在随机谕示模型中的自适应选择的消息攻击也是安全的结论。根据该安全分析，在另一方面，经修改的Schnorr签名方案可抵挡公钥替换攻击，即，只存在可能发现满足对应于指定的公钥的签名的一不同的公钥的可忽略不计的可能性。结果，得出本文所述的命题成立的结论。
考虑这样一种假设，即计算性Diffie-Hellman(ComputationalDiffie-Hellman：CDH)假设成立并且散列函数H2(·)是安全的单向散列函数，于是仅Alice(发送者)和Charlie(TTP)能够推断出示例性认证事务协议中的用于加密消息m的消息加密密钥k。考虑一证据，即仅Alice(发送者)能够产生有效签名(R1，σ)。换言之，保证参数R1由Alice生成，即没有人可假扮Alice来发送有效参数R1。因为散列函数H2(·)是安全的单向散列函数，推断消息加密密钥k的唯一方式是推断参数R2的值。该CDH假设暗示出从R1和ys中不可能推断出参数R2的值。因此，除知道r或xs的人之外没有人能够推断出k的值。这意味着只有Alice(发送者)和Charlie(TTP)能够推断出消息加密密钥k。
示例性认证事务协议可提供公平性。考虑一证据，即基于以上给出的描述，在正常地执行交换子协议时，即在Alice(发送者)和Bob(接收者)是诚实的且通信信道工作时，Bob接收Alice发送的消息，Alice从Bob接收收条，不涉及Charlie(TTP)。
同样，如果Alice和Bob两个人都是诚实的，但通信信道在执行交换子协议期间失效；则Alice可调用争端协议来要求来自Charlie(TTP)的帮助以完成交换。因此，公平性在这两种情况下都是成立的。在其它情况下，一示例性协议也可提供公平性，即Alice(发送者)和Bob(接收者)在执行协议的过程中无法相互利用，即使他或她恶意地行动。这些情况可如下归类：(1)Alice是诚实的，但Bob是恶意的；(2)Bob是诚实的，但Alice是恶意的；以及(3)Alice和Bob都是恶意的。
图8示出了可由争端协议处理的三个示例性情形800的框图。第一情形810涉及诚实的发送者和恶意接收者。第二情形820涉及恶意发送者和诚实的接收者。第三情形830涉及恶意发送者和恶意接收者。
图9示出了第一情形810即恶意接收者的示例的框图。为了解释该示例，考虑Alice是发送者且诚实，而Bob是接收者且是恶意的。还考虑Charlie是可信第三方。在该情形中，Bob的目标是在不向Alice发送其有效收条σB的情况下获取消息m。根据示例性认证电子邮件协议200，Bob可通过不向Alice发送其有效收条(按照框812)来在交换子协议220中进行欺诈。然而，根据协议200，在该情形中，Alice将不向Bob发送参数R2。然而，按照框814和816，Bob可通过执行争端子协议230来从Charlie获取参数R2。但在这种情况下，因为Bob必须在Charlie向Alice转发参数R2之前向Charlie发送其有效收条，所以确保了安全性。在争端子协议230中，Charlie还将收条转发给Alice。此外，只有Alice能够生成有效签名(R1，σ)。总之，如果Bob想要接收消息m，则按照框818，Bob必须直接或间接向Alice发送其有效收条。因此，示例性协议200可以在情形810中提供公平性。
图10示出了第二情形820，即恶意发送者的两个示例821、823的框图。为了解释示例821、823，考虑Alice是发送者且是恶意的，而Bob是接收者且诚实。还考虑Charlie是可信第三方。
在示例821、823中，Alice的目标是在不向Bob发送消息m的情况下获取Bob的收条σB，或者使Charlie在争端子协议230中中止。在协议200中，Alice可以在交换子协议220的两个步骤中的任一个中进行欺诈。
在示例821中，按照框822，如果Alice不向Bob发送授权数据(例如(CA，R1，R′，Dscm，sA)或允许其他人确保Alice是发送者的其它信息)，则按照框824，Bob将不向Alice发送其有效收条。
在示例823中，如果Alice不向Bob发送正确的(R1，R′)，则按照框826，Bob将向Alice发送有效收条。在该上下文中，“正确”意味着Charlie和Alice将产生相同的对称加密密钥k且R′＝H(R2)。然而，按照框828，Alice无法使用从Bob接收到的收条来向其他人证明Bob已经从她接收到正确的消息m，这意味着Alice接收到的收条是无用的。因此Alice必须在该步骤中向Bob发送经授权的且正确的信息(例如(CA，R1，R′，Dscm，sA))。在后一种情况下，如果Alice向Bob发送无效R2或不向Bob发送R2，则Bob可调用争端子协议来获取m。如果接收到的消息m不匹配其描述，则Alice从Bob获取的收条是无用的，因为她无法向其他人证明Bob已经从她接收到正确的消息m。总之，本发明的协议也可以在这种情况下提供公平性。
将一示例性认证事务协议与其他协议进行比较以评估性能。在乐观认证电子邮件协议的上下文中，其他协议基于公钥密码技术。公钥密码花费比对称密钥密码或安全散列函数多得多的时间。在公钥密码中，最费时的操作是模指数计算。模指数操作所花费的时间与单模乘法所花费的时间之比是与指数的位长度成线性比例的。结果，在出于将示例性认证电子邮件协议与其它认证电子邮件协议进行比较的目的的对协议效率的理论分析中，比较可忽略单模乘法和其它非公钥密码算法(诸如对称加密、对称解密和散列函数)。
一种比较协议基于ElGamal方案和Schnorr方案(被表示为Wan05a)。另一种比较协议基于RSA(被表示为Wan05b)。在效率比较中将示例性认证电子邮件协协议与这两个协议进行比较。在该比较中，使用EXP来表示ElGamal加密方案或Schnorr方案所需要的一个模指数操作所花费的时间。术语EXPRSA表示RSA签名或RSA解密所需要的一个模指数操作所花费的时间，EVRSA表示RSA验证或RSA加密所需要的一个模指数操作所花费的时间。假设所测试的示例性协议使用Wan05a中的群相同的群G，即使它是椭圆曲线上的有限域的乘法群或有限有理点群。
表1.示例性协议和其他协议的时间成本的比较。
Figure GPA00001094699100151
Figure GPA00001094699100161
其中：(1)Bob的签名算法所花费的时间；(2)Bob的验证算法所花费的时间；(3)配对计算所花费的时间；(4)在这种情况下，Alice只可向Charlie证明。
表1示出了示例性协议(Ex.P.)以及Wan05a和Wan05b协议的时间成本。出于该比较的目的，忽略设置阶段和证书验证过程中的时间成本。根据表1中的信息，与Wan05a相比，示例性协议在交换子协议中节省了一个模指数操作。例如，如果Alice(发送者)需要仅向TTP证明她已将消息m发送给Bob(接收者)，则一个协议在证明过程中节省一个模指数操作。如果Alice需要向其他人证明，则该示例性协议需要一个配对操作，这通常比Wan05a协议中所需要的两个模指数操作慢。示例性协议与Wan05b的比较由于这两个协议中所使用的不同的公钥密码系统而更复杂。Wan05b协议使用RSA而在Wan05a协议中使用ElGamal加密方案和Schnorr签名方案，并且示例性协议基于离散对数问题且因此可利用椭圆曲线密码(ECC)的优点，ECC使用比相同安全级别的RSA短得多的密钥并因此比RSA快得多。例如：密钥长度为2048位的RSA具有与密钥长度为224位的ECC相同的安全级别，且ECC-224在全长度模指数中比RSA-2048快7.8倍。因此，示例性协议也比Wan05b协议有效得多。总之，示例性协议比被认为是利用离线TTP的最有效的认证电子邮件协议中的两种的Wan05a和Wan05b协议有效得多。
如此处所描述的，各种示例性技术允许构造示例性认证事务协议。虽然各个示例涉及电子邮件，但其它这样的示例性技术可适用于其它类型的事务。示例性协议基于授权的Diffie-Hellman密钥协定。比较示出对于电子邮件事务，示例性协议在指数和通信数据的数量方面比常规认证电子邮件协议有效得多。由于其效率，示例性认证电子邮件协议适于在分布式环境中执行的应用(例如，分布式应用、web 2.0应用等)中使用。
如上所述，网络上的协议本质上是异步的。如果不存在可信方，则可容易地在顺序过程的某些步骤中进行欺诈。如此处所描述的，示例性认证事务协议使得能够在不具有可信第三方(TTP)的情况下通过诸如因特网等网络在两个“不可信”方之间进行信息(例如消息)的公平交换和不可否认的接收。在这一示例性方案中，交换中所涉及的两方中没有一方可进行欺诈以获取利益。这一公平交换协议具有许多潜在应用，诸如从一个主机传递至另一个主机的移动主体、通过给予贡献者稍后可转换成报酬的收条来鼓励用户与其他人共享诸如广告等内容或将这些内容分发给其他人的系统。
用于事务的示例性协议使得用户能够共享信息。例如，这一协议可以在分布式环境中实现并提供鼓励分布式环境中的用户(例如web用户)共享诸如照片、影片、歌曲等媒体的安全措施。这一协议可以在研究环境、法律环境、报酬环境等中使用。例如，在研究结果对于管理评审重要的情况下，管理机构可要求事务使用具有离线TTP的示例性协议来进行。在法律事务中，法庭提交和/或法律事务中的双方之间的提交可使用离线TTP来进行。在某些情况下，法庭(例如法庭人员)可担当TTP以确保诉讼各方交换电子邮件、法庭提交、证据等。
在web广告中，可以在必要时使用具有TTP的示例性协议来检查点击、支付或报酬。例如，广告方案可鼓励人们与其他人共享内容和广告。在Alice(发送者)和Bob(接收者)上下文中，当Alice向Bob发送具有广告的内容时，于是根据该方案，Bob接收内容，查看广告并向Alice发送收条(例如签名)。一旦Alice具有收条，她就能够提交该收条以要求传播广告的报酬。
示例性协议可以与诸如YouTube视频(例如因特网上的视频分布站点)等内容一起使用，其中认证电子邮件将人们定向到内容和广告。例如，Alice具有来自YouTube的内容并想要将该内容发送给Bob。因此，在示例性认证方案中，Alice向Bob发送该内容并且Bob向Alice发送收条。Alice然后将该收条发送到YouTube或关联方(例如登广告者)并收取报酬。进而，Bob可经由认证电子邮件将该内容发送到另一方(例如Mark)并且作为回报，接收收条。如果引发争端，则根据示例性协议，TTP可确定谁在欺诈。
在上述各示例中，效率可帮助加速内容分发，这可帮助内容在最短时间内到达尽可能多的人。
示例性协议规定了以保证争端解决机制的方式的双方之间的顺序交换。在这一示例中，各方可以是周期性地进行交换的两个服务器。例如，服务器A可将信息发送到服务器B的代理并且当服务器B接收到该信息时，服务器B可向服务器A发送收条。可使用TTP来解决服务器之间的争端。
虽然各示例将事务各方称为“不可信的”，但示例性协议可用于通信不正常或引发由TTP解决的其它问题的“可信”方情况。
图11示出了可用于实现各示例性组件并形成示例性系统的示例性计算设备1100。例如，图1的系统的服务器和客户机可包括设备1100的各种特征。
在一非常基本的配置中，计算设备1100通常包括至少一个处理单元1102和系统存储器1104。取决于计算设备的确切配置和类型，系统存储器1104可以是易失性的(诸如RAM)、非易失性的(诸如ROM、闪存等)或是两者的某种组合。系统存储器1104通常包括操作系统1105、一个或多个程序模块1106，并且可包括程序数据1107。操作系统1105包括基于组件的框架1120，其支持组件(包括属性和事件)、对象、继承、多态性、反射，并且提供面向对象的基于组件的应用程序编程接口(API)，诸如由华盛顿州雷蒙德市的微软公司制造的.NETTM框架的API。设备1100具有由虚线1108划分的非常基本的配置。同样，一终端可具有更少的组件，但将与可具有这一基本配置的计算设备交互。
计算设备1100还可具有附加特征或功能。例如，计算设备1100还可包括附加数据存储设备(可移动和/或不可移动)，诸如，例如磁盘、光盘或磁带。这样的附加存储在图11中由可移动存储1109和不可移动存储1110例示。计算机存储介质可包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。系统存储器1104、可移动存储1109和不可移动存储1110都是计算机存储介质的示例。计算机存储介质包括，但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储或其它磁性存储设备、或能用于存储所需信息且可以由计算设备1100访问的任何其它介质。任何这样的计算机存储介质都可以是设备1100的一部分。计算设备1100还可具有诸如键盘、鼠标、笔、语音输入设备、触摸输入设备等输入设备1112。还可包括诸如显示器、扬声器、打印机等输出设备1114。这些设备在本领域是公知的，因此不必在此详细讨论。
计算设备1100还可包含允许该设备诸如通过网络(例如考虑上述图1的网络150)来与其它计算设备1118进行通信的通信连接1116。通信连接1116是通信介质的一个示例。通信介质通常可以具体化为计算机可读指令、数据结构、程序模块等。
尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。

Claims (13)

1.一种至少部分地由计算设备实现的方法，所述方法包括：
向认证机构提供公钥（420）；
从所述认证机构接收绑定所述公钥的证书（424）；
向接收方发送消息描述、加密密钥的散列、所述证书以及用所述加密密钥加密的经加密的消息（516），其中所述加密密钥在可信第三方和发送方之间共享，并且其中所述可信第三方解决所述发送方和所述接收方之间的争端；
从所述接收方接收签名（616）；以及
响应于所述接收，向所述接收方发送用于解密所述消息的信息（620）；
接收所述接收方向所述可信第三方发送争端解决请求的指示，所述争端解决请求是响应于检测到所述散列和所述接收方执行的所述加密密钥的附加散列之间的差异来发送的。
2.如权利要求1所述的方法，其特征在于，还包括与所述经加密的消息一起发送所述消息的描述。
3.一种至少部分地由计算设备实现的方法，所述方法包括：
生成签名（250）；
从发送方接收消息描述、加密密钥的散列、经加密的消息和证书（604），其中所述经加密的消息是使用所述加密密钥来加密的，并且所述加密密钥在可信第三方和发送方之间共享，并且其中所述可信第三方解决所述发送方和接收方之间的争端；
向所述发送方发送所述签名（612）；
响应于检测到所述散列和所述加密密钥的附加散列之间的差异，从所述接收方向所述可信第三方发送争端解决请求；
从所述发送方接收用于解密所述消息的信息（620）；以及
解密所述消息（620）。
4.如权利要求3所述的方法，其特征在于，所述生成签名包括使用经修改的Schnorr签名方案来生成签名。
5.如权利要求3所述的方法，其特征在于，还包括在所述解密之前从所述发送方接收所述消息的描述并将已解密的消息与所述消息的描述进行比较。
6.如权利要求1或3所述的方法，其特征在于，所述方法采用了一种用于双方事务的乐观协议（200），所述乐观协议包括：
包括授权的Diffie-Hellman密钥协定的设置子协议（210），其中所述授权的Diffie-Hellman密钥协定包括在发送方和可信第三方之间共享加密密钥，并且其中所述可信第三方可任选地解决所述发送方和接收方之间的争端；
交换子协议（220），包括将消息描述、所述加密密钥的散列、证书以及用所述加密密钥加密的消息从发送方发送到接收方并将收条从所述接收方发送到所述发送方；以及
争端子协议（230），包括用于解决所述发送方和所述接收方之间的由于发送无效证书、由于发送无效收条、或者由于所述交换子协议（220）的中止而引发的争端的争端解决机制，其中所述争端解决机制进一步通过所述可信第三方解决所述发送方和所述接收方之间的至少由于所述散列和所述加密密钥的附加散列之间的差异而引发的争端。
7.如权利要求6所述的方法，其特征在于，所述事务包括电子邮件事务（115）。
8.如权利要求6所述的方法，其特征在于，所述交换子协议（220）还包括将用于解密先前从所述发送方发送到所述接收方的信息的解密信息从所述发送方发送到所述接收方。
9.如权利要求6所述的方法，其特征在于，所述交换子协议（220）还包括将信息从所述发送方发送到所述接收方并将所述信息与先前从所述发送方发送到所述接收方的信息进行比较，其中所述比较可任选地包括将消息与先前发送的消息描述进行比较，并且其中不利的比较可任选地调用所述争端子协议（230）。
10.如权利要求6所述的方法，其特征在于，所述争端子协议（230）包括可信第三方。
11.如权利要求6所述的方法，其特征在于，所述发送方和所述接收方经由在分布式计算环境中操作的分布式应用来交易。
12.如权利要求6所述的方法，其特征在于，所述设置子协议（210）包括将所述发送方的公钥绑定到所述发送方的证书，并且其中所述交换子协议可任选地包括将所述证书从所述发送方发送到所述接收方。
13.如权利要求6所述的方法，其特征在于，所述设置子协议（210）包括用于生成所述接收方的签名的经修改的Schnorr签名方案。
CN200880111327.9A 2007-10-08 2008-10-08 有效认证电子邮件协议 Active CN101821987B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/868,872 2007-10-08
US11/868,872 US8341410B2 (en) 2007-10-08 2007-10-08 Efficient certified email protocol
PCT/US2008/079129 WO2009048902A2 (en) 2007-10-08 2008-10-08 An efficient certified email protocol

Publications (2)

Publication Number Publication Date
CN101821987A CN101821987A (zh) 2010-09-01
CN101821987B true CN101821987B (zh) 2014-02-19

Family

ID=40524318

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200880111327.9A Active CN101821987B (zh) 2007-10-08 2008-10-08 有效认证电子邮件协议

Country Status (4)

Country Link
US (1) US8341410B2 (zh)
EP (2) EP3481003B1 (zh)
CN (1) CN101821987B (zh)
WO (1) WO2009048902A2 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7899800B2 (en) * 2006-08-18 2011-03-01 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US8806190B1 (en) 2010-04-19 2014-08-12 Amaani Munshi Method of transmission of encrypted documents from an email application
US20110282965A1 (en) * 2010-05-17 2011-11-17 Ifan Media Corporation Systems and methods for providing interactivity between a host and a user
US20140067678A1 (en) * 2012-09-02 2014-03-06 Mpayme Ltd. Dispute code system for secure mobile payment
US9420003B2 (en) * 2013-06-24 2016-08-16 Cisco Technology, Inc. Dynamic communication between secure endpoints
US9516061B2 (en) 2013-11-26 2016-12-06 Cisco Technology, Inc. Smart virtual private network
US9722798B2 (en) * 2014-02-10 2017-08-01 Security Innovation Inc. Digital signature method
US9735967B2 (en) * 2014-04-30 2017-08-15 International Business Machines Corporation Self-validating request message structure and operation
PT3188435T (pt) * 2015-12-28 2020-01-22 Lleidanetworks Serveis Telematics Sa Método para certificar um correio eletrónico compreendendo uma assinatura digital confiável por um operador de telecomunicações
US10505978B2 (en) * 2017-08-24 2019-12-10 Visa International Service Association Utilizing trust tokens to conduct secure message exchanges
EP3461073A1 (en) * 2017-09-21 2019-03-27 Lleidanetworks Serveis Telemàtics S.A. Platform and method of certification of an electronic notice for electronic identification and trust services (eidas)
CN108494559B (zh) * 2018-03-12 2021-01-08 北京航空航天大学 一种基于半可信第三方的电子合同签订方法
US11487886B2 (en) 2019-05-03 2022-11-01 International Business Machines Corporation Database private document sharing
ES2802420B2 (es) * 2019-07-10 2022-04-25 Univ Illes Balears Método para notificaciones y entregas certificadas basadas en tecnología blockchain

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5977086A (en) * 1997-03-07 1999-11-02 R.I.G.H.T. Method of inhibiting human immunodeficiency virus by combined use of hydroxyurea, a nucleoside analog, and a protease inhibitor
CN1943207A (zh) * 2004-04-19 2007-04-04 松下电器产业株式会社 移动节点的快速且安全的连接

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4956863A (en) * 1989-04-17 1990-09-11 Trw Inc. Cryptographic method and apparatus for public key exchange with authentication
CA2176032A1 (en) * 1994-01-13 1995-07-20 Bankers Trust Company Cryptographic system and method with key escrow feature
US6141750A (en) 1995-03-21 2000-10-31 Micali; Silvio Simultaneous electronic transactions with subscriber verification
US5638446A (en) 1995-08-28 1997-06-10 Bell Communications Research, Inc. Method for the secure distribution of electronic files in a distributed environment
US5699431A (en) * 1995-11-13 1997-12-16 Northern Telecom Limited Method for efficient management of certificate revocation lists and update information
JP3253060B2 (ja) 1997-12-25 2002-02-04 日本電信電話株式会社 相互認証方法及びその装置
WO1999035782A1 (en) * 1998-01-02 1999-07-15 Cryptography Research, Inc. Leak-resistant cryptographic method and apparatus
EP0936805A1 (en) 1998-02-12 1999-08-18 Hewlett-Packard Company Document transfer systems
DE69832535D1 (de) 1998-03-18 2005-12-29 Kent Ridge Digital Labs Singap Verfahren zum austausch digitaler daten
US20020049601A1 (en) 1998-10-28 2002-04-25 Nadarajah Asokan Optimistic fair exchange protocols
JP2001175468A (ja) * 1999-12-20 2001-06-29 Sony Corp ソフトウエア使用制御方法とその装置
AU2002252034A1 (en) 2001-02-22 2002-09-12 Bea Systems, Inc. System and method for message encryption and signing in a transaction processing system
JP4169942B2 (ja) * 2001-02-27 2008-10-22 インターナショナル・ビジネス・マシーンズ・コーポレーション コンテンツ利用方法、コンテンツ配信方法、コンテンツ配信システムおよびプログラム
US7136840B2 (en) 2001-04-20 2006-11-14 Intertrust Technologies Corp. Systems and methods for conducting transactions and communications using a trusted third party
US20040073790A1 (en) * 2001-07-13 2004-04-15 Giuseppe Ateniese Intermediated delivery scheme for asymmetric fair exchange of electronic items
US20030028495A1 (en) 2001-08-06 2003-02-06 Pallante Joseph T. Trusted third party services system and method
US7774411B2 (en) 2003-12-12 2010-08-10 Wisys Technology Foundation, Inc. Secure electronic message transport protocol
JP4665617B2 (ja) 2005-06-10 2011-04-06 沖電気工業株式会社 メッセージ認証システム，メッセージ送信装置，メッセージ受信装置，メッセージ送信方法，メッセージ受信方法およびプログラム
US20070124584A1 (en) 2005-11-30 2007-05-31 Microsoft Corporation Proving ownership of shared information to a third party
US7890757B2 (en) * 2005-12-30 2011-02-15 Novell, Inc. Receiver non-repudiation

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5977086A (en) * 1997-03-07 1999-11-02 R.I.G.H.T. Method of inhibiting human immunodeficiency virus by combined use of hydroxyurea, a nucleoside analog, and a protease inhibitor
CN1943207A (zh) * 2004-04-19 2007-04-04 松下电器产业株式会社 移动节点的快速且安全的连接

Also Published As

Publication number Publication date
US20090094452A1 (en) 2009-04-09
CN101821987A (zh) 2010-09-01
EP2201718B1 (en) 2019-01-16
WO2009048902A2 (en) 2009-04-16
WO2009048902A3 (en) 2009-05-28
EP3481003B1 (en) 2020-07-08
EP2201718A2 (en) 2010-06-30
EP3481003A1 (en) 2019-05-08
US8341410B2 (en) 2012-12-25
EP2201718A4 (en) 2017-07-19

Similar Documents

Publication Publication Date Title
CN101821987B (zh) 有效认证电子邮件协议
Wei et al. SecCloud: Bridging secure storage and computation in cloud
Zhou et al. Evidence and non-repudiation
US6282295B1 (en) Auto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers
JP5205398B2 (ja) 鍵認証方式
US20030190046A1 (en) Three party signing protocol providing non-linkability
US20100142704A1 (en) Cryptographic encoding and decoding of secret data
US6473508B1 (en) Auto-recoverable auto-certifiable cryptosystems with unescrowed signature-only keys
JP4932168B2 (ja) 新しいフェア・ブラインド署名プロセス
EP2792098B1 (en) Group encryption methods and devices
US6243466B1 (en) Auto-escrowable and auto-certifiable cryptosystems with fast key generation
US20040073790A1 (en) Intermediated delivery scheme for asymmetric fair exchange of electronic items
Küpçü Official arbitration with secure cloud storage application
US20040221158A1 (en) Digital signature and verification system for conversational messages
CN108449326A (zh) 一种异构可否认的认证方法和系统
AU8656498A (en) Auto-recoverable auto-certifiable cryptosystems
You et al. On the efficient implementation of fair non-repudiation
JP4146252B2 (ja) 不正者特定可能な匿名通信方法、それに使用される利用者装置、及び中継サーバ装置
Wang et al. A new dependable exchange protocol
Wang et al. How to protect exchanged secrets in the fair exchange protocol with off-line TTP
Witzke et al. Key management for large scale end-to-end encryption
Zhang et al. A unified approach to a fair document exchange system
Saxena et al. A digital cash protocol based on additive zero knowledge
Oniz et al. An optimistic fair e-commerce protocol for large e-goods
JP2004282575A (ja) 対話鍵生成法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: MICROSOFT TECHNOLOGY LICENSING LLC

Free format text: FORMER OWNER: MICROSOFT CORP.

Effective date: 20150423

C41 Transfer of patent application or patent right or utility model
TR01 Transfer of patent right

Effective date of registration: 20150423

Address after: Washington State

Patentee after: Micro soft technique license Co., Ltd

Address before: Washington State

Patentee before: Microsoft Corp.