使用混合公共密钥加密策略来授权电子邮件的系统和方法

专利名称：使用混合公共密钥加密策略来授权电子邮件的系统和方法
技术领域：
本发明通常涉及电子邮件通信。特别地，本发明涉及使用公共密
钥加密签名来授权发件人和收信人之间的email的系统和方法。
背景技术：
电子邮件(email)现已成为大量的组织、公司和个人的主要通 信手段。电子邮件的简单、高效，更重要的是它几乎没有成本，使得 它得到了广泛的使用。不过正是这些优点对于全世界的email用户而 言又成了问题，因为他们正遭受到通常被称为"垃圾邮件滥发人，， (spammer)的滥用，来发送大量的未经请求的、非法的email,而发 件人的成本却几乎为零。
针对这种"垃圾邮件，，问题已提出了多种解决方案。以下是当前已 提出的几种主要方案
* 过滤法:在这种情况下，利用用户生成的列表，或用数学算 法推导出的一组规则将收件人接收到的email分类。这种过滤法的例 子是白名单、黑名单、以及Bayesian过滤器。尽管这种技术可在短期 有用，但对于长期的email交换则不切实际，因为它们会导致垃圾邮 件滥发人(spammer)的竟争(arms-race)，并且经常会造成伪-肯 定(合法的email被丟弃)或伪-否定(非法的email被接受)，尽管 这种方案被越来越多地釆用，但它们仅是权宜措施，垃圾邮件滥发人 数的增多，使得过滤机制失去了作用。
* 询问-回答:在这种情况下，收件人(或他使用的邮件阅读软 件)在收到来自陌生发件人的email时，产生并发送一个对所述的发 件人的询问。这一询问是自动应答器很难回答的，但人却很容易回答。该发件人一旦回答了该询问，他就被添加到收件人的合法发件人的列 表上了 。尽管该系统可能的确减少了收件人收信箱内的"垃圾邮件，，，但它给发件人附加了一个被许多人认为是反直觉(conter-intutitive) 的负担。因此，这一方案未被广泛地采用。* M:在这种情况下，发件人必须使用某种形式的加密方法 为他的email加上签名。于是收件人就可以检验发件人的身份，并且， 由此通过将该签名和该发件人已知的加密身份进行匹配来检验该 email的真实性。该方案现有的实现方式的问题是他们需要对收件人 和发件人一方的加密机制做过多的理解。此外，目前还没有任何一种 所提出的方案可提供一个可行的(scalable)、加密身份交换机制。因 此，该方案未^皮广泛采用。* 契约(Escrow)和合同(bond):在这种情况下，发件人必 须将一定量的钱款放到契约里或提供合同以便将email发送给他的收 件人。相反，如果收件人感到或可以证明发件人发出了一个非法的 email,他就可以收取这笔钱款。除了是否可行的问题以外，该方案的 主要问题是它假设收件人的行为是诚信的，然而这一点却是不可担保 的。因此，该方案未^皮广泛地采用。* M:在这种情况下，发件人必须为一张邮票支付费用以便 发送一封email。代替现款， 一张邮票也可能要求CPU做大量的计算， 或要求发件人一方做一些其它的操作。总之，该方案对于很少发送 email的发件人是容易的，但对于那些发送垃圾邮件的人则变得十分 昂贵。而该方案的问题是它要求对现有的基础设施做大量的改造， 以便收款或者检验CPU的计算结果。因此，该方案未被广泛地采用。*服务器软件的改造:在这种情况下，要对email服务器上的 软件进行修改以便实现新的email验证策略。这种验证可能需要提供 一个已知用户的列表，使远程服务器可以向起始服务器检验身份，或 可以由起始服务器提供某种形式的加密签名。这种策略以及其变体需 要对全世界的大量email服务器进行改造，因此是不可行的。因此， 该方案未,皮广泛地采用。* 商标签名:在这种情况下，发件人可以在他们的标题上使用 一个商标以确保他们的email不是垃圾邮件，并且商标的所有人确保 他将起诉不当使用他的商标的任一方。该策略的问题是，它假设入侵 者的数量相当少或只居住在法律允许这种起诉的地理位置。不过，实 际上这种假设几乎不能成立，而这种签名实际上几乎已变成了垃圾邮 件的肯定标记。因此，该方案未被广泛地采用。目前还有其它几个现有的和建议中的方案，包括上述策略的组 合。不过目前还没有一种能成功地提供对垃圾邮件的可行解决方案。美国专利/>开号2004/0024823 (DelMont)描述了一种方法，由 此，发来的email可在到达目的收件人的SMTP服务器之前被截取并 得到验证服务器的检验，以便确定它们是否是垃圾邮件并由此抛弃它 们。尽管DEL MONTE正确地指出为解决垃圾邮件问题彻底改造现有 email系统是笨拙的、也是不可能的，并提供了在此方面失败的几个 现有方案的例子，但是他提出的方案本身也受许多限制，并产生了许 多问题。首先，通过将验证服务器设置在从中接收email的网络和发 起SMTP服务器之间，对于负责这一基础设施的管理员而言，网络管 理就变得更加困难，因为SMTP服务器性能的任何不协调症状，都需 要对验证服务器性能及它与其余的网络组件的交互进行分析。而且， 在验证服务器上所用的验证策略类似于"白名单"，其由用户建立的、 他们愿意从其接收email的用户的列表组成，并且由于发件人面临只 能联系其已经在"白名单，，中的收件人的问题，因此这一策略被公认为 是不可行的。还应当提到的是，"白名单，，是一个经常容易回避的技术， 因为经常没有办法来检验emai标题中的字段是否已被伪造。美国专利/>开号2004/01346% ( Norris等人)描述了一种将邮件 发件人的身份检验为可信任的方法。该方法依赖发件人在注册时提交 与他的签名有关的生物数据，而且这一信息被存储在一个数据库中。 当用数字钢笔为他要发送的邮件签字时，就将发件人的生物数据与已 在数据库里找到的生物数据做比较。如果该数据匹配，注册人数据就 被加载到邮件上的存储设备上，并且可能被管理数据的受信任的第三方进行数字签名和/或加密。在接收该数据包时，邮件服务或邮递员(carrier)检验该发件人的确是受信任的，为该发件人开出帐单(如 有必要)，将该数据包发送给收件人。另一种建议的具体实施例中， 发件人请求收件人的email地址，并且由邮递员联系收件人来检验他 们是否接受该数据包的递送。首先，这一应用适合物理邮件并不企图要求所述过程绝对适合于 email。即使出于争辩的目的，我们i人可了适于物理邮件的专利也可以 应用于email,该专利应用所描述的过程却不能有效地解决垃圾邮件 问题(必须注意，如下面所讨论的，NORRIS等人并不打算解决物理 的垃圾邮件问题，)。 一则是，邮递员，其通过扩展收件人的邮件服 务器有可能被比喻地标记成网络，但它要为识别伪造的或未受信任的 进入邮件负责。正如在DELMONTE所强调的，由于现有email服务 器的数量很大，因此现有的email网络基本设施的改造存在极大的问 题，同时由于系统管理员管理对现有基础设施进行的主要改造所需的 工作量很多，因此改造是不切实际的。更不用说，该方法力图解决的问题是物理邮件发件人发送的有可 能是对收件人很危险的包裹；特别是对2001年炭疽信件事件的反映。 这里并不打算探讨如何防止发件人发送未经要求的或垃圾物理邮件的 问题。美国专利公开号2004/0003255 ( Apvrille等人)公开了这样一种 系统，其中发出邮件服务器包括一个专用硬件卡来负责为进入的email 提取摘要，并将日期和时间附加到该摘要上，以创建一个时间戳，并 将该结果签上个人数字签名。这样，发出的邮件包含可克服发件人造 假和墓改的时间戳，并且由此就可由收件人检验该邮件。特别地，该 方法适合用来解决email时戳通常不可靠的问题。尽管讨论了数字签 名email的问题，该方法并不打算也并不要求有助于解决垃圾邮件问 题。即使把它用于这一目的，它也会遭到其它垃圾邮件解决方案在发 出邮件服务器被改造后所遭受到的相同问题的困扰。考虑到现有邮件 服务器的数量和全世界的系统管理员要为改造他们所管理的所有邮件服务器所作的工作，这样的方案不能广泛得到采用。此外，用来为email 签名的个人密钥对所有发件人来说是通用的。因此，每个发件人仅限于具有一个加密身份。美国专利公开号2004/0181703 (Logan等人)描述了这样一种方 法，由此发件人能获得由授权认证(CA)签名的公共密钥-个人密钥 对。这对密钥由CA签名以便换取发件人的保证，即他将服从一系列 指导(良好行为准则)来使用个人密钥对email签名。当发送email 时，发件人必须将一个保证附加到他的email上并指出该发件人发送 给其它收件人的类似email的数量，然后用他的个人密钥对该email 签字，并将它发出给收件人。 一旦接收到邮件，收件人就从CA中取 回发件人的公共密钥并检验该email的确是来自于该发件人，且得到 了一个本身由CA签名的个人密钥的签名。在所提出的方案中，发件人必须管理好他自己的加密身份(例如， 如果他的个人密钥已经泄漏，那么他必须通知CA)。所提出的方案 的一个缺点是公共/个人密钥的概念可能不像，比如说，用户名和口令 那样普及或直观以便于理解。因此，LOGAN等人所提出的方案，提 出了如何采纳的问题，这取决于其提倡者培训大部分计算机用户涉及 使用公共/个人密钥设施的机制和责任的能力。另外，只有在签名时，CA才为发件人的密钥签名，因此CA就 没有可能的对发件人发送的email的类型和质量进行的运行时间验 证。此外，也没有方法使CA监控发件人的系统是否已经泄漏。也没 有办法使CA对发件人发送的email的数量进行限制。所以尽管滥发 邮件的发件人实际上有可能被Logan等人所提出的方案抓住，但是还 是没有一种机制可以在尽可能短的时间内或以自动方式识别该滥发 者。这样就需要一个email验证系统和方法，对终端用户而言极其简 单，并且也不必教导用户新的概念。用户最多需要知道在验证服务器 上他的帐户的用户名和口令，并且如上所述，用户名和口令是新用户 很容易掌握并已被大部分现有的计算机用户很好地理解的概念，这些用户可能已经需要知道他们的用户名和口令以登录他们的计算机和/或已经有了 一个email帐户，需要用户名和口令来接收和发送email。美国专利公开号2004/0059454 ( Barret等人)描述了这样一种系 统，由此发件人发送的电子数据可以在电子数据的发件人和目的收件 人之间的中间设备上加以截取。收件人可在中间设备处被识别，并且 电子数据可被修改以便反映标识发件人的信息，而后，修改后的数据 被发送给目的收件人。假定发件人的识别是在发件人和收件人之间的中间设备上完成 的。Barret等人的方法需要对现有的email基础设施进行改造。像那 些要求对现有的email基础设施进行改造的其它垃圾邮件解决方案一 样，并且正如DEL MONTE所强调的那样，大规模地使用和采用这种 方法是有问题的。此外，BARRET等人建议发件人的识别必须基于发 件人的地址。然而，任何一个这样的方案，其中不要求发件人参与带 有签字授权的验证过程，都会使滥发的大门敞开。此外，Barret等人规定在中间设备上附加的信息"会使发件人身 份马上被指定的收件人所识别。，，不过，如无第三方的检查装置，收件 人可能不会真正相信这种瞬间的识别。此外，正如在APVRILLE等人的例子中，发件人对于是否修改 他的外发消息以便可靠地识别他是没有选择权的。因此，正像前面所 提到的，每个发件人都仅限于有一个加密身份，发件人不能够发送不 符合签名授权所建立的规则的通信量。更不用说在Barret等人的例子 中，发件人不能对精确的元数据或对他的email所做的修改进行控制 (因此收件人就不能认为发件人个人应对此负责)了。因此，就需要这样的一种email验证系统和方法，保持现有的邮件 服务器基础设施不变，并且由此不会受到现有用户使用这样的系统和 方法的影响。此外还需要一种系统和方法，对与收件人发起联系没有特殊要 求，所述收件人不认识发件人、以前也没看见过他的地址、或在发起 联系之前从没有与发件人联系过。发明内容本发明的目的是提供一种至少能克服上面表出的众多缺点之一，并至少能满足上述众多需要之一的email验证系统和方法。本发明的另 一个目的是提供一种通过使用可为email签名的公共 /个人密钥密码防止email造假的email验证系统和方法。本发明的另一个目的是提供一种根本不需要对现有的email的基 础设施做任何变动或仅做极小的变动的email验证系统和方法。本发明的另 一个目的是提供一种能保证发件人的通信能得到收 件人优先处理的email验证系统和方法。此外，本发明的另一个目的是提供一种email验证系统和方法， 包括验证服务器能一个接一个地为每个发出的email签名，由此它可 以自动方式随机或系统地记录一个发件人发出的邮件是否满足可被分 类为垃圾邮件的基本准则。本发明的另外的目的是提供一种email验证服务器，它能将某些 情况通知那些管理它的人员，以便它们也能帮助避免发件人的身份被 窃并通知他他的系统可能已经潜在地泄漏了 (这一过程也可以自动化 并达到一定程度)。本发明的另一个目的是提供一种email验证服务器，作为发件人 如想对他的email进行签名，他就可以任意地选择来与之进行交互的 独立的实体，其余的email处理像引入验证服务器之前那样执行。本发明的另一个目的是提供一种email验证系统和方法，其中 email的发件人具有一个验证服务器的帐户，并且此后在获得允许对 每个单个的email进行签名之前，必须在验证服务器上验证他自己。本发明的另一个目的是提供一种email验证系统，其中一个签名 的email的收件人必须从数据库中取回发件人的公共密钥，之后才可 以检验发件人的email的确是用适合的个人密钥签名的。因此，该验 证系统就可以作为收件人检验发件人身份的第三方。根据本发明，提供了 一种经由邮件服务器来验证从发送站到接收站的email的系统，包括数据库，与所述发送站相分离，用于储存与发件人有关的数据， 所述与发件人有关的数据包括用于每个发件人的公共密钥和个人密 钥，个人密钥被保持为使每个发件人不可得；签名模块，与所述发送站相分离并且可连接到所述数据库，用于 响应于email签名请求，为email产生签名，该签名是作为在所述数 据库中找到的与发件人相关联的个人密钥的函数而产生的；组合模块，可连接到签名模块，用于经由邮件服务器将签名的 email发送到接收站，所述签名的email由签名和email组合而产生；公共密钥模块，可连接到接收站和数据库，用于响应于公共密钥 请求，返回在数据库中找到的与发件人相关联的公共密钥；发送模块，集成到所述发送站中并且可连接到所述签名模块，用 于在email发送到接收站之前产生email签名请求；以及接收模块，与所述接收站相关联并且可连接到所述公共密钥模 块，用于产生在接收到所述签名的email时触发的公共密钥请求，并 且利用公共密钥模块返回的公共密钥验证所述签名的email的签名。根据本发明还提供了一种经由邮件服务器来验证从发送站到接 收站的email的方法，包括如下步骤a) 与发送站相分离地存储与发件人有关的数据，所述与发件人有 关的数据包括用于每个发件人的公共密钥和个人密钥，所述个人密钥 被保持为使每个发件人不可得；b) 在将email发送到接收站之前，从发送站产生email签名请求；c) 响应于email签名请求，与发送站相分离地为email产生签名， 该签名是作为在所述与发件人有关的数据中找到的与该发件人相关联 的个人密钥的函数而产生的；d) 经由邮件服务器将签名的email发送到接收站，所述签名的 email由签名和email的组合而产生。e) 产生在接收到该签名的email时触发的公共密钥请求；f) 响应于公共密钥请求，返回在与发件人有关的数据中找到的与发件人相关联的公共密钥；以及g)利用所述返回的公共密钥验证该签名的email的签名。 优选地，发送模块联系验证服务器，所述验证服务器首先将发件 人识别成被允许通过该服务器进行发送，其次，为email签名为该发 件人的个人密钥的函数。在接收到签名的email时，收件人就可通过 联络验证服务器、请求发件人的公共密钥以及利用该公共密钥验证包 含在email中的签名来检验发件人的身份是否被授权。验证服务器可 以将签名的email发送到现有的邮件服务器，或可以只将此签名返回 给发件人，以便用发件人现有的发出email服务器来与原来的email 一起发送签名。优选地，虽然发件人不能对他的个人密钥进行访问，但他可以提 供一个帐户，可能要收取费用，以便登录到验证服务器并对他的email 签名。这和现有的方案有很大的不同，因为发件人不能对他的加密身 进行充分地控制，可是他的email的合法性并不要求所涉及的服务器 有任何改动，不管是在发件人一端还是在收件人一端。此外，在发件 人一端的签名过程和在收件人一端的验证过程，最好用他们各自的 email客户端(用来读、写、发送和接收email的软件)也可以使用插 件来透明地执行。优选地，在滥发的情况下，验证服务器要通过检验报告该攻击的 收件人所提供的签名来识别该攻击发件人。然后可对发件人的帐户采 取行动，可能是强制罚款，或禁止该发件人再给该收件人发送信息。该email验证系统最好包括* 验证发件人、为mail签名，为诸如收件人的第三方提供公共 密钥并检验攻击者的身份的验证服务器；* 发件人和收件人使用的、为了给email签名或验证email而 与验证服务器通信的软件，以及* 实现该系统所需的全部附加软件和硬件。优选地，通过本email验证系统和方法，发件人能够对他的元数 据和内容进行控制。


下面将参考以下的服务对优选实施例给出详细的说明，其中相似 的编号指代的是相似的元件。图l是根据本发明的email验证系统的实施例的方框图，其中发 送邮件服务器和接收邮件服务器是同样的服务器。图2是根据本发明的email验证系统的另一实施例的方框图，其 中发送邮件服务器和接收邮件服务器是分离的服务器。图3是根据本发明的email验证系统的简化方框图。图4是根据本发明的email验证系统的另一实施例的方框图，其中签名的email从验证服务器发送到接收站。图5是根据本发明的email验证系统的另一实施例的方框图，其 中数据库和公共密钥模块与验证服务器相分离。图6是根据本发明的email验证系统的另一实施例的方框图，其 中接收模块集成在接收邮件服务器中。图7是示出email验证系统中用于执行发件人email的验证和签 名的组成部分的方框图。图8是示出email验证系统中用于执行将发件人的公共密钥送交 给收件人的组成部分的方框图。图9是示出新发件人注册处理的一种可行的实施例的方框图。
具体实施方式
值得注意的是，在图1-9中虚线框用来表示可选组件，可以使用 也可不使用，或者也可以用其它组件一起来替换。也可以添加新的组 件。虚线箭头表示一组可能性。参考图1和2,本发明的email验证系统经由邮件服务器16来验 证发送站2和接收站14之间的email (标题、正文主体、附件等)。 在图1中，发送邮件服务器和接收邮件服务器是同一个邮件服务器16, 而在图2中，发送邮件服务器18和接收邮件服务器20彼此间分离的。该系统包括与发送站2分离的数据库3，用于存储与发件人有关 的数据。与发件人有关的数据包括用于每个发件人的公共密钥和个人 密钥。个人密钥被保存以使每个发件人不可得。因此，发件人不知道 他的个人密钥。发送站2可以是可以从其发送email的典型的桌面工 作站、服务器、或任何其它适当的设备。发送站2可以运行任何操作 系统(例如Windows 、 MacOS 、 Linux⑧等)和通常用于取回/阅 读/发送email的任何一种email客户端应用程序(例如Eudora⑧、 Outlook 、 Outlook Express 、 Netscape 等)。发送模块4，如email客户端插件集成到发送站2中并且与发件 人现有的email客户端应用程序进行通信。利用除email客户端插件 外的其它软件的其它配置也是可行的。例如，发送模块4本身就可以 是email应用程序。发送模块4在发件人试图向接收站14发送将要签 名的email时受到触发。发送模块4在将该email发送到接收站14之 前产生email签名请求(如箭头10所示)。签名模块6与发送站2相分离，并可连接到数据库3 ，它接收email 签名请求10。该签名模块可集成在验证服务器8中。因此，发送模块 4联系验证服务器8并与验证服务器8实现适当的用户识别握手例程， 一旦被成功地识别为合法的发件人，发送模块4把将要签名的email 发送到验证服务器8。正如以下将要说明的，发送模块4之后接收来 自验证服务器8的签名。可连接到签名模块6的组合模块12接着将签 名组合到发出的email上，由此就获得了签名的email,并将此签名的 email发出，就像它通常通过现有的邮件服务器(SMTP服务器)所 做的那样。组合模块12可以集成到发送站或验证服务器8中(如图4 所示)。在这种情况下，如果在发件人的email应用程序中配置的发出 SMTP服务器是验证服务器8而不是现有的发送邮件服务器18,那么 email发送请求(例如，当发件人按压email应用软件的发送键时)能 自动产生email签名请求10。因此，email签名请求IO可以是该email 向验证服务器8的传输。例如，利用验证服务器8对发件人的验证，可以在发件人和发件人发起邮件服务器之间，根据现有的验证方法来 提供。如前所述，验证服务器8可与发送站2连接。典型地，验证服务 器8是一台服务器、多个服务器或是具有复杂服务器配置、运行鲁棒 且安全的操作系统的网络，或是能够处理高网络通信量的这种操作系 统的网络配置(例如Linux⑧、Solaris 、 AIX⑧等)。签名模块6可接收来自发送模块4的email签名请求10。验证服 务器8能实现适当的识别握手，以便确定发件人是否有权使他的email 被签名， 一旦确定了有权签名，签名模块6就找回发件人的个人密钥， 产生作为从数据库3中找到的与发件人相关联的个人密钥的函数的签 名，并且将该签名返回组合模块12。组合模块12将该签名和该email 组合在一起，然后经由发送邮件服务器18将该签名的email发送到接 收站14。发送邮件服务器18通过集成到验证系统中而可能保持不变。 发送邮件服务器18接收来自发送站2的发送请求，并能进行适当的握 手以便将签名的email送到接收邮件服务器20，例如接收SMTP服务 器。验证服务器8还能实现许多其它的功能，如对发件人在给定时间 内发送的email数量进行控制等。验证服务器8可以包含在一个可在 因特网上公开访问的网络服务器中或可包含在驻留于用于签名email 目的的一个组织的个人网络中的网络设备中。验证服务器8还有可能 充当SMTP服务器，因此可将签名的email转发给现有的SMTP邮件 服务器。接收邮件服务器20是收件人的现有的SMTP服务器。接收邮件 服务器20可以通过集成到验证系统中而保持不变。典型地，接收邮件 服务器20由发件人的SMTP服务器18或验证服务器8来连接，它接 收签名的email、存储签名的email以便让收件人取回，进行适当的握 手以便允许收件人取回任何他所收到的email,当收件人请求时，为 收件人取回所存储的email,并将它们传送给收件人的email客户端软 件。接收站14可以是一个典型的桌面工作站、 一个服务器或可从一个邮件服务器取回email的任何其它适当设备。接收站14可以运行任 何操作系统(例如Windows , ，MacOS 、 Linux 等)以及任何典型 地用于取回/阅读/发送email的email客户端应用程序(例如Eudora 、 Outlook 、 Outlook Express 、 Netscape⑧等)。接收模块24和接收站14相连接。接收模块24可以是与收件人 现有email用户客户端应用程序相连接的email客户端插件。接收模 块24，其可以是如上所述的用于连接验证服务器8并将email加以签 名的相同的插件，在当收件人将email作为正常email获取的一部分 接收时被触发。在这一时刻，接收模块24检验该email是否含有来自 验证服务器的签名。接收模块24产生一个在接收到签名的email时触 发的公共密钥请求32来取回发件人的公共密钥。 一旦接收到公共密 钥，接收模块24检验该签名的email的签名，并相应地为该email做 上标志供收件人查看。例如，如果该email含有合法的签名，该email 就作为收件人收件箱中包含的email列表的一部分被加亮显示。使用 除email客户端插件外的其它软件的其它配置也是可以的。例如，代 理端口监控程序(proxy daemon )可以过滤那些不含有签名或含有非 法签名的email,以使收件人即使在他的收件箱内也看不到它们。公共密钥模块22可连接到接收站14和数据库3上。公共密钥模 块22接收来自接收模块24的公共密钥请求，用于从数据库3中取回 与发件人相关联的公共密钥。公共密钥模块22查找所请求的公共密 钥，取回它，并且如果找到它就将它返回给接收模块24。公共密钥模 块22可以是独立于验证服务器8的服务器，可能具有不同的网络地址 和/或不同的物理位置，或从外部看来，和验证服务器8具有相同的网 络地址或设置于相同的硬件上。它的位置、可见性和与其它系统组件 集成的可能性都不能改变它的作用和性能。本系统将确认email的合法性的任务放在发件人一方。参考图3, 发送模块2在将email传送给收件人之前，利用发件人特定的个人密 钥由在验证服务器8上的签名模块(未示出)为他的email加以签名 (箭头40 )。这签名的email随后或者通过验证服务器8本身或者使用发送邮件服务器18传送给接收邮件服务器20 (箭头42 )。在从接 收邮件服务器20中提取了签名的email之后(箭头44)，接收模块 24联络验证服务器8上的公共密钥模块22 (未示出)(箭头46)并 请求发件人的公共密钥。接收模块24还可以緩存已经获取的公共密钥 以备将来使用。使用发件人的公共密钥，接收模块24可以检验该email 的确是该发件人所发。虽然发件人必须要求有一个在验证服务器8上 的帐户，但收件人不需要有这种帐户，尽管在验证服务器8上拥有帐 户可能为收件人提供好处；对发件人的黑名单以及实现终端对终端的 加密交换即是这样的两个例子。除了图l和2之外，图4-6示出了根据本发明的email验证系统 的其它几个可能的实施例。当然，也可以考虑其它的实施例。例如， 验证服务器8可以是单个的物理机器，替代地，也可以是一组独立的 物理机器。图4示出了集成到验证服务器8中的组合模块12，以及将签名的 email发送到发送邮件服务器18或接收邮件服务器20的情况。在图5中，数据库3和公共密钥模块22独立于验证服务器8。 在图6中，接收模块24集成到接收邮件服务器20中。 如图7所示，发件人使用OpenSSH远程登录套件登录到验证服 务器8 (箭头50)。签名模块除了其它用于此目的的模块外还可以包 括验证引擎53。在这种情况下，可以有一个数据库62来验证登录(箭 头52)。 OpenSSH可用于a)检验发件人的确接入了验证服务器的服 务，b)确保验证服务器8和发送模块4之间的交换，c)允许发送模块4 和验证服务器8之间的通信，即使发件人的ISP正在过滤SMTP端口 。 然而，也可以用其它的软件组合来提供这种性能。使用HTTP连接的 SSL就是这样的例子。实际上，通过HTTP在发送模块4和验证服务 器8之间隧道传输所有的通信是可能的，只要这是唯一不能被发件人 的ISP过滤的服务。还可以采用用户建立的连接机制。 一旦建立连接， 验证引擎53就可以从数据库3取回发件人的个人密钥(箭头54)。 使用该个人密钥，验证服务器8就可以将信息和个人密钥馈送给签名模块6，它可以是诸如GPG的加密软件64 (箭头56)。为了避免发送大量的附件让验证服务器8来进行签名，发件人 email的可以代之发送该附件的hash校验和和email正文主体，而后 二者都由验证服务器8来签名。而后，该签名的email,作为由该加 密软件在发件人所提供的数据上运行的结果，或者可以使用传统的邮 件服务包，如Sendmail，经由现有的邮件服务器传送到接收邮件服务 器20 (箭头58 )、或者如前所述，可仅将生成的签名回送给发件人以 便他使用他现有的email服务器来发送。不考虑正在使用的实际的传 送机制，为了系统结构的目的，可定制签名。例如，收件人列表和其 他邮件标题也可以是该签名的一部分，以避免出现非法email的伪报 告(即，收件人声称他们接收到了 一个email,而实际上该email是盗 得的并将它的标题做了墓改以便对发件人进行诬告)。当然，在该系统中还可以实现大量的改进和特色。如果收件人也 是一个成员(在此系统里有一个帐户)或是按个人的选择、或是在接 收了收件人认为是非法的email之后，他可以被允许将发件人列入黑 名单。在这种情况下，验证服务器8可以检查发件人的收件人并拒绝 为目的地是那些将该发件人列入黑名单的收件人的email签名。也可 以使用GnuPG以外的其它公共密钥加密软件，诸如PGP等或者专为 本发明开发的加密套件。为了避免吸引想要滥用该策略的滥发者的潜 在的暴力破坏密钥，验证服务器8可以使用那种有失效日期的密钥， 代替那种从不失效的密钥。加密密钥的尺寸和它们持续时间将按在那 段时间可用的计算能力来选取。 一旦过期，密钥的尺寸就必须增加和/ 或它们的持续时间可能也必须缩短，以便将破坏密钥的难度保持在足 够的程度，使得滥用者不能成功地破坏系统。也可以考虑使用随机失 效日期(对用户是不透明的)。也可以实现一个评价(rating)系统，如在许多web站点(例如 amazon.com、 ebay.com等)已经存在的系统来评价发件人。由此， 收件人可以被允许按发件人所发送的内容来评价发件人。收件人所使 用的、与验证服务器进行对话的软件接着就可以询问服务器该发件人的评价。利用这一信息，收件人的软件就可以选择或对所接收的消息 进行过滤或按发件人的评价对消息做不同的显示。数据库3包括用于每个发件人的以下信息* 成员身份ID;* email地址( 一个成员可以决定用 一个成员关系为一个以上 的地址服务)；以及* 个人和公共密钥也可以添加与发件人的email的签名有关的其它信息字段。例如， 可以添加一个字段，用于列出将发件人列入黑名单并阻止他发送的收 件人。此外，值得注意的是公共密钥也可以替代地保存在另一数据库 中。一旦接收到签名的消息，接收模块24可以1 )认出该签名的消息； 2)从公共密钥模块22中取回发件人的公共密钥；3)使用该公共密钥、 签名以及适当的公共密钥加密软件来检验该email的签名。所有的收 件人，不管他们有没有验证服务器8的帐户，都被允许取回发件人的 公共密钥。通过在验证服务器8上拥有帐户，收件人也可被允许创建 一个他不想从其接收任何邮件的用户的黑名单。这可能涉及到建立一 个用于维护黑名单的数据库，或它可能涉及到用提供给收件人的软件 实现黑名单。除了黑名单以外，收件人可以令验证服务器8在一定的 时间内保持来自特定发件人的消息。在这种情况下，例如验证服务器 8向接收邮件服务器20发送消息。那么收件人的接收邮件服务器20 也可以通过自动完成上面列出的步骤1 )到3 )来检验email的签名(如 图6所示)。图8示出了用于处理来自收件人的公共密钥请求的公共密钥模块 22的系统的可能结构。接收模块24和公共密钥搜索引擎81通信(箭 头80)，而后者又和公共密钥数据库90通信(箭头82)以便取回收 件人所要求的公共密钥。所述公共密钥数据库可以是用于存储个人密 钥的同一数据库3。如果收件人没有安装适合同验证服务器8通信的软件，发件人的email就应仍是人工可读的。本质上，取决于本发明是如何实现的， 发件人的email应当作为一个GPG签名的邮件，或一个具有包含签名 的额外附件的email出现。图9示出了实现向该系统注册一个新的发件人(新成员)的一个 可能的结构。典型地，该新成员可以使用他的Web浏览器连接到一个 安全的Web站点(可能是利用OpenSSL的Apache)并且填写所需要 的字段以创建一个新帐户(箭头100),诸如姓名、地址、信用卡号 码等。Web服务器120而后将该信息提供给注册引擎122(箭头102 )， 后者检验成员的信息并联络信用卡清除服务器124 (箭头103 )以验证 用户提供的信用卡信息。 一旦这一步成功，注册引擎122就控制成员 添加引擎126(箭头104)来执行为成员注册的许多任务。通常，这将 涉及1)为新成员创建一对个人和公共密钥(箭头105) ， 2)向成 员签名数据库3提供个人密钥(箭头106) ， 3)向公共密钥数据库90 提供公共密钥(箭头107 ) ， 4 )将新用户添加到登录数据库62 (箭头 108)，以使该成员可以登录并且使email被签名。以及5)在成员数 据库63中为该用户创建一个新条目(箭头109)。成员数据库63可 以包括用于每个成员的以下条目 个人成员身份ID (内部使用的数字ID)*公共成员身份ID (用于用户登录的字母数字ID) *加密的信用卡号码 *接触信息 用户优先权还可以添加更多的字段。例如，成员可以被允许使用Web接口 从官方(official)卖家订购/不订购新闻信息。这种添加4艮容易扩展， 以容易地使用户使用数字身份管理系统。该用户 一旦被添加到成员数 据库，他就被给予成员身份注册确认(箭头110)，它含有字母数字 用户-id (可以由用户提供并已被验证它确实不存在)和登录用的口令 (也是可以由用户提供并且验证了其长度和复杂性)。在该系统最初的使用过程中，用户可被允许成为免费成员以便对该系统进行评估。这样，他们可不必提供他们的信用卡信息。而是向 成员提供条形码图像来代替，成员必须把它们打印出来并通过传统的 信件将其发送回去以便确认他们是否已经注册。这一过程将会阻止那 些潜在的滥发者通过创建大量非法帐户来破坏系统。此外，每个发件人被允许发送的消息的数量可以被限制为每小时一定的数量，如100 件(IOO)。这样，即使成员的系统被泄漏了，它不能用来发送无限量 的email。该最大值可以保持不变就像节流阀(throttle) —样，即使 对于付费用户也是如此。想要发送更多邮件的成员可能必须支付附加 的费用和/或证明他们的需要是正当的。在对该实现进行最初评价期 间，最好提供不同的质量认证。这样，来自付费发件人的email的质 量认证可能比来自参与该系统免费试用的发件人的email的质量认证 更好。这一点可以通过使用不同的加亮颜色用于不同的email认证类 型，或使用某些其它的过滤形式使收件人看清楚。也可将这种提供不 同认证等级的系统扩展到本发明的产品实现的存续期间。既然如前所述本发明不可能处理成员的系统安全已经受到威胁 和被用来发送非法的email的情况，于是将该情况的解决留给该成员 负责升级他的抗病毒软件或为他的系统发送了非法的email支付罚 款，将来可以附加权宜的措施和加强手段以便减少这种破坏的影响。除了上述的基本功能之外，还可以附加许多强化手段。例如，验 证服务器8可充当发件人和收件人之间进行端对端加密通信的媒介， 只要它们两者都有验证服务器8的帐户。在这种情况下，成员们在验 证服务器8上申请成员身份时，可能必须在他们的系统上创建一对个 人和公共的密钥，并且必须将他们的本地公共密钥提供给验证服务器 8,以便让其他的成员使用。因此对每个用户来说服务器的数据库里有 两个公共密钥， 一个用来验证发件人， 一个用来允许成员安全地交换 数据。所述加密交换也可由验证服务器来签名。为了记录下验证服务器8的服务机构的抱怨，非法email的收件 人可以为这种服务机构提供所收到的email的逐字拷贝，包括签名和 邮件标题(包含发件人的地址)。该email的来源可用数据库3加以检验，也可以采取适当的行动，可能要先征得用户的同意。 一个可能 的后果是收件人将发件人列入黑名单。这样，这就可能需要在适当的 数据库中加入适当的条目。此外，可能有为第三方提供用以签名他们自己用户的email而实 现的验证服务器8的设备版本。例如，像IBM⑧和Yahoo!⑧等公司希 望拥有他们自己的验证服务器而不依赖外部的服务器。在这种情况下， 他们可以实现上述发明以签名他们自己的用户的email的网络设备。 这种设备有可能与中央服务器实现最小程度的同步化并提供可与其它 的这种设备直接通信的接口。从这种设备发送的email可能需要两个 签名， 一个用于用户、 一个用于设备。用户的签名可被用于如上所述 的单个验证服务器。设备密钥可用来保持可对他们使用本发明的特权 做出解释的设备所属的组织。例如大量地发送email可能要被禁止。 为了避免滥发，这种设备可以是防伪造和防篡改的。可以使用某种 keepalive信号来确认设备是否总是在线。某种远程-登录性能可能也 与保证该设备适当运行有关。为了适当地处理这种设备，可以使发件 人所用的软件适于处理多个验证服务器。验证服务器ID可以作为由 验证服务器所提供的签名的一部分由发件人随同邮件一起发送。该设 备的某种验证可以用中央验证服务器来执行。例如该设备的公共密钥 不可能从该设备本身得到，但是可以从中央授权的验证服务器中得到。验证设备之间的同步的例子可以是黑名单。如果joe@ibm.com 被helther@sudo.org列入黑名单。那么处理sudo.org的该设备、或者 如果sudo.org没有设备，则主验证服务器将联络服务ibm.com的设备 并通知它在其数据库中为helther@sudo.org加上黑名单规则。这可能 涉及到用一个数据库专门处理黑名单。虽然已经参考附图和上面的描述说明了本发明的具体实施例，但 是本领域的技术人员能够更加清楚地了解到，在不背离本发明的本质 的情况下在此可以作出各种变化和修改。
权利要求
1. 一种经由邮件服务器来验证从发送站到接收站的email的系统，包括数据库，与所述发送站相分离，用于储存与发件人有关的数据，所述与发件人有关的数据包括用于每个发件人的公共密钥和个人密钥，个人密钥被保持为使每个发件人不可得；签名模块，与所述发送站相分离并且可连接到所述数据库，用于响应于email签名请求，为email产生签名，该签名是作为在所述数据库中找到的与发件人相关联的个人密钥的函数而产生的；组合模块，可连接到签名模块，用于经由邮件服务器将签名的email发送到接收站，所述签名的email由签名和email组合而产生；公共密钥模块，可连接到接收站和数据库，用于响应于公共密钥请求，返回在数据库中找到的与发件人相关联的公共密钥；发送模块，集成到所述发送站中并且可连接到所述签名模块，用于在email发送到接收站之前产生email签名请求；以及接收模块，与所述接收站相关联并且可连接到所述公共密钥模块，用于产生在接收到所述签名的email时触发的公共密钥请求，并且利用公共密钥模块返回的公共密钥验证所述签名的email的签名。
2. 根据要求l所述的系统，还包括验证服务器，与所述邮件服 务器相分离，其中所述签名模块和所述组合模块集成在该验证服务器 中。
3. 根据要求l所述的系统，还包括验证服务器，与所述邮件服 务器相分离，其中所述组合模块集成在发送站中并且所述签名模块集 成在验证服务器中。
4. 根据要求l所述的系统，还包括附加邮件服务器，其中一个邮件服务器与发送站相关联并且构成 发送邮件服务器，另一个邮件服务器与接收站相关联并且构成接收邮件服务器；以及验证服务器，与发送邮件服务器和接收邮件服务器相分离，所述 签名模块集成在所述验证服务器中。
5. 根据要求4所述的系统，其中组合模块集成在所述发送站中， 该组合模块具有经由发送邮件服务器将签名的email发送到接收站的 功能。
6. 根据要求4所述的系统，其中组合模块集成在验证服务器中， 该组合模块具有将签名的email发送到发送邮件服务器的功能。
7. 根据要求4所述的系统，其中组合模块集成在验证服务器中， 该组合模块具有将签名的email发送到接收邮件服务器的功能。
8. 根据要求4所述的系统，其中公共密钥模块集成在验证服务器中。
9. 根据要求l所述的系统，还包括验证服务器，与所述邮件服 务器相分离，签名模块集成在该验证服务器中，email签名请求包括 用于发件人登录到验证服务器的与发件人有关的登录数据，所述验证 服务器包括与数据库相关联的登录模块，用于验证在该数据库中找到 的与发件人有关的登录数据并授权发件人有权进入签名模块。
10. 根据要求1所述的系统，其中email签名请求包括该email 的正文主体和该email的附件的hash校验和，签名模块具有为该email 的正文主体产生签名并且为附件的hash效验和产生签名的功能。
11. 根据要求4所述的系统，其中接收模块集成在接收站中。
12. 根据要求4所述的系统，其中接收模块集成在接收邮件服务器中。
13. 根据要求l所述的系统，还包括集成到接收模块中的公共密 钥数据库，用于存储由公共密钥模块返回的公共密钥。
14. 根据要求1所述的系统，还包括可连接到数据库的注册模块， 用于遵循在注册模块控制下的发件人注册过程，根据发件人提供的信 息，将添加的发件人注册到数据库中。
15. 根据要求14所述的系统，还包括可连接到注册模块的密钥 生成模块，用于产生与添加的发件人相关联的公共密钥和个人密钥， 所述与附加的发件人相关联的公共密钥和个人密钥被保存到该数据库 中。
16. —种经由邮件服务器来验证从发送站到接收站的email的方 法，包括如下步骤a) 与发送站相分离地存储与发件人有关的数据，所述与发件人有 关的数据包括用于每个发件人的公共密钥和个人密钥，所述个人密钥 被保持为使每个发件人不可得；b) 在将email发送到接收站之前，从发送站产生email签名请求；c) 响应于email签名请求，与发送站相分离地为email产生签名，的个人密钥的函数而产生的；d) 经由邮件服务器将签名的email发送到接收站，所述签名的 email由签名和email的组合而产生。e) 产生在接收到该签名的email时触发的公共密钥请求；f) 响应于公共密钥请求，返回在与发件人有关的数据中找到的与发件人相关联的公共密钥；以及g) 利用所述返回的公共密钥验证该签名的email的签名。
17. 根据要求16所述的方法，其中步骤d)在发送站执行。
18. 根据要求16所述的方法，其中步骤c)和d)在独立于邮件服 务器的验证服务器上执行。
19. 根据要求16所述的方法，还包括附加邮件服务器，其中一 个邮件服务器与发送站相关联并且构成发送邮件服务器，另一个邮件 服务器与接收站相关联并且构成接收邮件服务器；以及其中步骤c)是 与发送邮件服务器和接收邮件服务器相分离的验证服务器上执行的。
20. 根据要求19所述的方法，其中步骤d)在发送站执行，步骤 d)的邮件服务器是发送邮件服务器。
21. 根据要求19所述的方法，其中步骤d)在验证服务器上执行， 步骤d)的邮件服务器是发送邮件服务器。
22. 根据要求19所述的方法，其中步骤d)在验证服务器上执行， 步骤d)的邮件服务器是接收邮件服务器。
23. 根据要求19所述的方法，包括在步骤c)之前的附加步骤， 用于将发件人登录到验证服务器上。
24. 根据要求19所述的方法，其中步c)包括为email的正文主 体签名和为email的附件的hash效验和签名。
25. 根据要求19所述的方法，其中步骤e)在接收站执行。
26. 根据要求19所述的方法，其中步骤e)在接收邮件服务器上执行。
全文摘要
本发明提供了一种使用混合公共密钥加密策略授权电子邮件的方法和系统。在一个实施例中，发件人联系验证服务器，所述验证服务器首先将发件人识别成被允许通过该服务器进行发送，其次，使用个人密钥来为email签名以便发送给收件人。在接收email后，收件人就可通过联络验证服务器、请求发件人的公共密钥以及利用该公共密钥验证包含在email中的签名，来检验发件人是否被验证服务器授权。验证服务器可以自己将email发送到现有的邮件服务器，或可以只将此签名返回给发件人，以便用发件人现有的发出email服务器将原来的email和签名一起发送给收件人。
文档编号H04L29/06GK101218782SQ200580004630
公开日2008年7月9日 申请日期2005年2月11日 优先权日2004年2月12日
发明者卡利姆·雅格莫 申请人:克里普提瓦公司