PKI(公开密钥构架).doc

DPKI（公开密钥架构）上次谈了一些量子加密的问题，乌龟同学正好也在问WPKI，U哥解答的很清楚了，特别是最后很关键的补充。无聊之中再试着清理一下自己的头脑，也来谈谈PKI（Public Key Infrastructure，公开密钥架构）。PKI之前的加密方法（包括有名的DES算法）都有一个缺陷，就是用来解密的密钥和用来加密的密钥是相同的。这样的话，就避免不了解决发送者和接受者之间既安全又方便地传送密钥的问题了。说白了就是，我写了一封信，把它装在箱子了，再上锁，然后邮寄给你；如果我有什么好的方法将钥匙安全地送到你手中的话，你自然能打开箱子读到我的信了（假设邮差是无法暴力打开箱子的，一定要有钥匙才行）。问题就是人类千百年来就是想不出怎样安全地传递这把钥匙，似乎逻辑上是不可能的。现在让我们一起看看各种方法。一把锁不够那就试试看两把锁。我还是写了一封信，把它装在箱子了，再上锁，然后邮寄给你。你收到后再加一把锁（你自己有钥匙），然后再邮寄给我。我收到后把我的锁给解开了，第三次麻烦邮差GG再把箱子递给你，这一次你收到后就能用你的钥匙打开箱子读到我的信了。注意在这个繁琐的过程当中，邮差只能接触到锁（你的和我的），但是他没办法接触到两把钥匙中的任何一把，所以不存在传递钥匙的问题。大家也许会说，这么简单的方法，用得着那么多年才想出来吗？问题在于发送信息不是真的加把锁头那么简单，加密算法其实就是一个数学函数，输入是要加密的明文，输出是已加密的密文。还记得函数的一个特征吗，就是虽然函数的反函数等于本身，但是套加一个以上的函数后，如果要恢复到原来的数值，必须注意在求反函数时的次序。比如说信件明文是1，我的锁是加1（解锁当然是减1啦），你的锁是乘以2（解锁是除以2）。我先加锁，信件成了1 + 1 = 2，再发给你。你收到2后再加你的锁：2 x 2 = 4，又发给我了。我收到后把我的锁解开：4 - 1 = 3，再发给你。最后你解开自己的锁：3 / 2 = 1.5。Oops，和原来的不一样啊。函数与锁头的不同就在于求反函数时，次序很关键，而解锁的次序却是无关紧要。定义一函数y = (a x) % b（a的x次方的结果，除以b以后得到的余数）a和b都是质数。在发送任何信息之前，我们先互相见面，共同选好一对质数a和b，假设a = 17而b = 31。现在看看我们怎样利用这个函数来传送密钥再次提醒一下，我们现在讨论的不是怎样利用密钥去加密明文，而是怎样安全地传送密钥。首先我选一个数字，比如说8，将它代进函数y，得到(17 8) % 31 = 18；你也选一个数字，比如说5，也将它代进函数y，得到(17 5) % 31 = 26。接着，我打电话给你，告诉你我的计算结果18，同时你也告诉我你的计算结果26。现在，我将你给我的的计算结果26换掉y函数里的质数a，得到(26 8) % 31 = 25；你也将我给你的计算结果18换掉y函数里的质数a，得到(18 5) % 31 = 25。像变魔术一样，我们得到的结果是一样的哦（这里不给出数学上的证明）。这样，我们可以用25作为我们这次通信的密钥，然后我们可以用任何加密算法（比如DES算法）加上这个密钥来对明文进行加密。注意到质数a和b的选择是我们事先在保密的情况下选好的，在这一对质数不泄漏的前提之下，就算有第三方知道了我们交换的数字18和26，他也无法算出我们通信时所用的密钥25的。当我们要换密钥时，只需要各自重新选择一个数字后再通一次电话，或者再次见面重新选取另外一对质数。大家可以试试看下面的小程序（随意选择不同的参数）：这个方法有个缺陷，假设我要将保密信件email给你，我先选一数字，代入函数后将计算结果email给你，你收到后知道我要发保密信件，也选一数字带入函数计算后再将结果发给我，我要收到你的计算结果后才能得到新的密钥，再将保密信件用密钥加密后email给你。在有时差的情况下，这一来一回有时需要两天时间。其实我也可以先做一把只有我能打开的锁头，然后复制很多份到处公开派发，谁想寄信给我的话就将信件发在箱子后用我的特制锁头上锁，再寄给我，这样问题不就解决了吗？注意到我公开派发的是锁头，钥匙却只是我自己有。这其实就是PKI的精髓了，公开密钥（public key）其实是锁头加密时用的密钥，私人密钥（private key）就是钥匙解密时用的密钥。不同于上面所举的例子，这一对密钥是不一样的，不过这会不会也和“两把锁方案”一样在数学上是行不通的呢？我们知道很多操作很容易进行反向操作，恢复到原位；比如说给出一个数字，乘以2后要恢复到原数，只需要除以2就行了。但有些操作比较难以进行反向操作，比如我们将蓝色的油漆和黄色的油漆混在一起变成绿色的，要再将它恢复成蓝色和黄色的油漆就困难多了（也许是不可能）。和混合油漆相类似，选两个质数相乘后得到一合数，要再将它分解成原来的两个质数就不那么简单了。比如我们看到数字527，用笔算的话，要花一段时间测试后才能分解成17x31，但是心算17x31都不算很困难。假设我任选一对质数a和b，还是假设a = 17而b = 31，它们的乘积n = 17 x 31 = 527。我再接着选一数字m（这里有一条件，m必须和(a - 1) x (b - 1) = 480互质），为了方便起见，我们就再选一质数，假设m = 11。接着，由公式(c x m) % (a - 1) * (b - 1) = 1先计算出我的私人密钥c： (c x 11) % (16 * 30) = 1 = (c x 11) % 480 = 1 = c = 131 （推出这一步需要用欧几里德算法，方法从略）现在我可以把n = 527和m = 11这对数字（公开密钥）印在我的名片上到处派发，任何人想发加密email给我时，就先将信息代入函数y = (x m) % n，比如你的信息是x=65（字母A的ASCII码），那么y = (65 11) % 527= 65 (1 + 2 + 4 * 2) % 527= (65 1 % 527) x (65 2 % 527) x (65 4 % 527) 2 % 527= (65 x 9 x 81 2) % 527= 44现在你把y = 44发给我。现在我可以利用我的公开密钥c = 131来解密你的信息了：x = (y c) % n = (44 131) % 527 = 44 (1 + 10 * 13) % 527 = (44 1 % 527) x (44 10 % 527) 13 % 527= (44 x 36 13) % 527= 65Bingo! 现在我们看到了，加密用的公开密钥n = 527和m = 11和解密用的私人密钥c = 131是完全不同的，这就实现了公开的加密用的锁头和保密的解密用的钥匙不同的目的了。这就是RSA算法的原理。注意在这里，公开密钥527和私人密钥131是对称的，就是说用527加密过的信息可以用131去解密，反之，用131加密过的信息也可以用527去解密。大家也许会说，其实第三方可以从公开密钥n = 527和m = 11分析出527的两个质因子a = 17和而b = 31，然后再由公式(c x m) % (a - 1) * (b - 1) = 1计算出我的私人密钥c = 131。不过我们知道当我选的两个质数a和b足够大时，就算用电脑计算，也不能很有效地从ab的乘积中分解出a和b的数值。在实际应用上，只要能有程序能产生一对足够大的质数，并且使得它们的随机性较大（不同发信者产生的那对质数都是不一样的），那么我们就能用这对质数的乘积作为我们的公开密钥。U哥提过：“我的Treo600用DES，一秒钟几次乃至几十次都OK，但是RSA，我等过一个小时”。DES速度快，但是它是对称密钥结构，有传送密钥上的问题；RSA虽然没有传送密钥的问题，但速度比较慢，我们可以试试看新的结合方案：我可以先用DES密钥加密我的信息，然后再用你的RSA公开密钥来加密我的DES密钥，最后将两者一起发送给你。你收到后，先用你的RSA私人密钥来解开我的DES密钥，然后再利用它来解开我的DES加密信息。这样，我用RSA加密的只是DES的密钥，要加密的内容少，所以RSA的速度缺点不成问题；我用DES加密大的文件，可以利用到DES的速度优势，另一方面，我通过RSA把我的DES密钥发给你，这也利用到了RSA不存在着传送密钥的优势。这就是PGP算法的原理。除了加密（encryption）之外，我们也经常听到验证（authentication），其实验证和加密在公开密钥架构下是一对双胞胎。在加密的情况下，所有想发信给我的人，都用我提供的公开密钥对信息进行加密，而我能用我的私人密钥对收到的信息进行解密。但是，我也可以反过来做，用我的私人密钥对一段无关紧要的信息进行加密，然后附加在我的明文信件发给任何有我公开密钥的人。接受者收到后可以用我的公开密钥进行解密，得到那段无关紧要的信息。这段经过私人密钥加密过的无关紧要的信息其实就是数字签名（digital signature），如果你能用我给的公开密钥解开信息的话，就说明这封信确实是我发给你的因为只有用我的公开密钥才可以解开用我的私人密钥加密过的信息。（一般认为RSA的安全性等价于大数分解质因数的难度，不过并没有严格的证明。在普通计算机上实现RSA的速度差主要是大数运算库的速度差造成的。大数运算在英语中称为arbitrary precision问题，有很多开源的library可用，我试过几个，都不怎么理想。可能极限情况也就如此了，那些library从实现上来说都是效率挺高的。另外一个流行的公密钥算法是elliptic，是基于平行线在无穷远处相交的数学假设，原理不象RSA那么容易理解，不过最终实现并不复杂，效率和RSA相比差别不是很大。公钥算法就多了，早期的DES使用64bit钥匙，但是实际上有用的是56bit，另外8个bit是奇偶校验，注意不要用奇偶校验位来作为密钥位，这样会降低被破解的难度。56bit DES在网上被一群流氓破解之后，现在时髦的是triple DES了，三次DES运算加密。不过美国鬼子在过去的几年中搞了一个替代DES的算法大赛，历时3年，其实最终入选的5个算法都很优秀，包括rijndael, mars, serpent, blowfish，还有一个名字忘了，很容易查到的。最终胜出的是rijndael，该算法就成了米国的新标准，别名叫做AES，a表示advanced。所有的公密钥或者单钥算法都是公开源码随意使用的，但是公密钥算法中用到的其他库函数，比如大数运算库，就麻烦了，很多是GPL的，不能随意使用；而自己写的东西，如果不是对CPU的汇编指令很熟悉的话，性能恶臭恶臭的。这是实际开发中要仔细考虑的一个问题。QUOTE:Originally posted by 乌龟 at 2004-8-4 06:03 PM:（这里有一条件，m必须和(a - 1) x (b - 1) = 480互质）什么叫互质? 两数互质的意思是说这两个自然数的最大公约数为1，即(a, b)=1指定若干个自然数的最大公约数是指这样的一个自然数，这个自然数能够整除这几个自然数中的每一个，并且不存在一个比它大的自然数，这个自然数也可以整除这些自然数的每一个。自然数a能够整除自然数b，是指存在这样的自然数k，使得等式b=k*a成立，记为a|b。蜗牛哥哥,小的想问个问题:WTLS协议中,在建立通信连接中,有一个步骤Server Key Exchange Message,里面说要communicate the pre-master secret:either an RSA public key to encrypt a secret with, or EC Diffie-Hellman parameters with which the client can complete a key exchange (with the result being the pre-master secret).这个pre-master secret是个什么东西?在RSA和EC各算法中充当了什么角色啊?哦,还有能在介绍一把EC算法吗?先复习一下以前讲过的一些概念密钥架构一般分为非公开的和公开的；前者的密钥是对称的，解密时用的密钥就是加密时用的那把优点是速度快，缺点是要通信双方要事先私底下选好密钥，例子有DES算法；后者的密钥是不对称的，解密时用的密钥不是加密时用的那把缺点是速度慢，优点是允许通信双方通过非加密通道交换密钥，例子有RSA算法。ECC（Elliptic Curve Cryptography，椭圆曲线密码学）和RSA算法一样，属于公开密钥架构，是基于椭圆曲线的一种密码学。椭圆曲线其实不是椭圆，指的是y2 = x3 - px - q一类的函数，它与Andrew Wiles于1994年证明费马最后定理也有关联。ECC算法也涉及到群的概念，等以后有时间另外开帖子讨论群和椭圆曲线吧。ECC一般被认为是当前最强的非对称密钥架构，美国国家标准技术局（National Institute of Standards and Technology）对RSA密钥长度的最低要求是1024位，但是对ECC密钥长度的最低要求是160位（它们的保密程度等价于80位的对称密钥架构，比如DES）。一般说来，在破解难度同等的情况下，ECC密钥长度只是对称密钥长度的两倍。和一样，ECC在商业上主要是由Certicom开发的，它们也有破解奖金哦：/index.php?action=res,ecc_solution，109位的ECCp-109在2002年11月被破解时用了超过10000万台PC不间断地运行了549天：/index.ph . rchive&view=121（可惜得到的奖金才$10000）。ECC目前的建议密钥长度是163位，大家可以看到，破解时间大概是109位的108倍。ECC可以采用不同的群，较常见的有Diffie-Hellman，ElGamal discrete log cryptosystem和DSA。上面说了，ECC算法涉及比较深的数学知识，现在先讲讲TSL和pre-master secret，等有时间再谈谈Diffie-Hellman算法。weiyangge同学好像是数学专业的，要不有劳他给讲解讲解？TSL（Transport Layer Security）是Netscape基于SSL（Secure Sockets Layer）建立的一种新协议。HTTPS的一般实现方式就是HTTP通过TSL或者SSL运行。TSL的目的就是怎样使通信双方通过非加密通道，取得一致的session key作为密钥。假设乌龟同学要买巨硬，上网付款给U哥，我们可以这样实现TSL：乌龟：U哥U哥，我是乌龟。我手头上有4种加密算法哦：RSA，Diffie-Hellman，ElGamal和DSA，你选一种吧。U哥：好的，我选RSA，我发给你我的X.509证书，里面有我的RSA公开密钥。乌龟：收到证书。我创建一pre-master secret，然后用你的RSA公开密钥加密后发给你。U哥：收到已加密的pre-master secret，我可以用我的RSA私人密钥解密后得到pre-master secret。现在我可以根据你发来的pre-master secret创建一session key，用我的RSA私人密钥加密后发给你。乌龟：收到已加密的session key，我可以用你的RSA公开密钥解密，现在我们有了相同的session key，可以用它作为对称加密算法（比如DES）的密钥，对我的信用卡资料进行加密了 注意上面举的例子是RSA，U哥当然也可以选择Diffie-Hellman，情况是类似的，希望上面的例子能解答乌龟同学的一些疑问。QUOTE:Originally posted by 乌龟 at 2004-8-20 04:55 PM:你演示的算法里,一共有4个需要赋值的参数,哪个是pre-master?其他的又是什么? 那个算法是演示DH算法的，不是RSA。那个演示中上面两个数是双方协商好的，一个是质数。可以通过明文来协商，被偷听到也无所谓。后面两个数双方各生成一个且不需要通知另一方。这样就可以生成共同的session key来进行加密解密。证明我已经写过了。DH算法中的那些数好像被称作Key Material，中文应该是密钥材料吧。QUOTE:正好问我牛过一个问题：在Kerberos的规范中，session ticket有两个属性：renewal period和expiration time。当到达expiration time后，这个ticket就无效了，必须立即断开session，重新协商一个ticket。但是在expiration time之前， 每过renewal period长度的时间这个session的两端可以renew这个ticket。这样就可以经常变换session key以保证通信的安全，但又不需要每次都生成全新的session ticket。不知道这个renew的具体过程是怎样的？看来加密的各个概念确实容易搞混，谢谢weiyangge在上面帮我解释了 也许这么说会比较清楚：DES是一种单一密钥的加密/解密算法，由于加密和解密用的密钥是一样的，所以通信双方要想办法通过非加密通道取得一致的密钥。另外几种比较有名的有IDEA，还有U哥提到的3DES，AES等等。DH是一种怎样通过非加密通道取得一致的密钥的方法。通信双方在事先达成某种协议的情况下（weiyangge所说的Key Material），可以通过非加密通道随时达成新的共同密钥，它的缺点我在上面提到了。RSA是不对称密钥的加密/解密算法，每次产生的密钥永远是一对：用密钥A加密的信息要用也只能用密钥B去解密；反之，用密钥B加密的信息要用也只能用密钥A去解密，它才是我们讲的公开密钥架构。这个“只能用”的特征使得公开密钥架构的应用不只限于加密/解密，还可以应用到验证身份上，这我在在上面也解释过了。讲完了密钥，现在可以讲讲使用密钥的策略。首先，密钥不只 可以用来加密明文，还可以用来加密另外一个或多个密钥算法可以不同，比如说你可以用加密算法A去加密“加密算法B所用的密钥”。其次，通信双方可以利用不同的加密算法和不同的组合，不厌其烦地将密钥加密后再发来发去，目的其实只有一个，就是上面所提到的“怎样通过非加密通道取得一致的密钥”。我个人觉得算法需要比较深的数学基础，而策略需要更多的灵感和创造力。PGP就是一种使用RSA去加密IDEA密钥的策略，说明在上面。TSL也是一种使用密钥的策略:1）U哥发给乌龟他的RSA公开密钥。2）乌龟收到后随机选一个数字X（这就是pre-master secret），用U哥的RSA公开密钥加密后发给U哥。3）U哥收到已加密的数字X，用他的RSA私人密钥解密后得到数字X。3）U哥用数字X作为种子，经过某种算法产生一新的数字Y（这就是session key），用他的RSA私人密钥将Y加密后发给乌龟。4）乌龟收到已加密的数字Y，用U哥的RSA公开密钥解密后得到数字Y，把它作为DES的密钥。5）现在乌龟和U哥可以利用DES和数字Y相互传送信息了。上面所提到的DES和RSA只是作为例子说明TSL的原理，实际应用时可以选不同的加密算法。Kerberos其实也还是一种策略，用SPN（安全协议范式security protocol notation）表达的话就是：可能大家一开始看到上面的公式会觉得不知所云，我先解释一下其中的基本概念：A，B和S是三个不同主体。K是两个主体之间共享的密钥，比如KAB就是A和B之间共享的密钥，KBS就是B和S共享的密钥，KAS就是A和S共享的密钥。大括号就是将括号里面的东西用某种算法加密的意思，比如TA + 1KAB就是将TA + 1后用A和B共享的密钥加密。注意到公式里面根本没提到用的是什么算法，比如TA + 1KAB里的大括号，可以是DES，也可以是AES。因此，策略和算法是分开的。在说Kerberos之前，先补充一下传统DH算法的一个漏洞。在我以前所举的例子中，当通信双方在交流计算结果时，有可能有第三者C在中间截取了A的计算结果，把它换成C自己的计算结果后再发给B；同样地，他也截取B的计算结果，也把它换成C自己的计算结果后再发给A。这样A和B之间以为他们取得了共同密钥X，其实是A和C取得了共同密钥Y，而且B和C也取得了共同密钥Z。A发给B的信息看起来是A用X加密，然后B用同样的X去解密；事实上是A用Y加密，被C在中间截取后用Y解密后再用Z加密，然后发给B，B收到后再用Z解密。问题出在哪里呢？问题就在于验证。任何通过非加密通道交流后产生共同密钥的机制，如果没有验证的辅助，理论上在交流过程中可能会受到第三方的攻击。因此，验证不只是在实现方式上和加密是双胞胎，而且是加密的必要辅助手段。经过验证程序增强的DH算法叫STS（Station-to-Station）协议，它是IPSec的组成部分之一。Kerberos是希腊神话中冥王Pluto的三头看门狗，拉丁文是Cerberus，它是Echinda和Typhon所生的几个很有名的怪兽之一。其它的几个是Orthus（看管红牛群的双头犬，被大力神Heracles所杀），Chimera（羊身狮头蛇尾的怪物，被骑着飞马的Bellerophon所杀），Hydra（九头蛇，也是被大力神Heracles所杀）严重走题，还是言归正传吧。当初MIT发明这种网络验证协议的时候可能看中了这条看门狗，所以用它来做名字了。Kerberos的主要目的是防止信息在传送途中被第三者截取甚至修改后重发给接受者。自从Windows 2000后，微软开始使用Kerberos作为电脑之间的验证协议，我想这也是weiyangge感兴趣的原因吧？ 微软的Kerberos Ticketing System在实现方面跟MIT原来的Kerbero协议当然有些小差别，不过我还是习惯先讲讲原理。假设我们在一个局域网内，由很多台用户工作站和几台服务器（邮件服务器，文件服务器，打印服务器等等）组成。这种结构便于管理而且花费也比较低（对比一下每台工作站配置一台打印机）。当用户A想要某种服务（邮件，打印或文件）时候，他只需要向相应的服务器发出请求就行了。可是我们有一个问题要解决，就是怎样使得服务器能安全而且有效地验证请求者的身份，不然的话我们的系统也太不安全了。方案一：我们可以在每台服务器上存取所有用户的密码，每次收到请求时都验证一下。这个方案的缺陷在于如果用户改密码的话，所有服务器上的密码也要更新。方案二：用户有密码，我们也可以给所有的服务都设置密码，然后我们再建一新的服务器，就叫验证服务器S吧，它储存着所有用户的密码和所有服务的密码。当用户A请求服务B时，他不是直接发送请求到服务器B，而是发送到验证服务器S。服务器S当然会问A他的用户密码进行验证，如果它确认了请求者的确是A之后，下一步就是要告诉服务器B用户A的请求合法了。大家说它要怎么做呢？最简单的办法当然是它把服务B的密码给用户A，不过他要是知道了服务B的密码，下次还会再找验证服务器吗？看来又要用到我在上面一直提到的“将密码再加密”的策略了：服务器S可以先生成一张服务券：用户A的名字，用户A申请时所登录的工作站IP，用户A请求的服务B的名字，用服务器B的密码对其进行加密后，再发回给用户A。用户A收到加密后的服务券后只要把它再发给服务器B，服务器B发现收到的加密服务券可以用它自己的密码解密的话，就可以确认这是一个合法请求了假设这张加密过的服务券在从服务器S发回用户A的过程中被公司内部其它用户截取并复制了一份，他还是不能用，因为他的工作站IP和服务券不吻合。服务券就是看门狗的第一个头。可是，这个方案还是有缺陷：首先，用户A每次请求新服务时，服务器S都要他再次提供密码，用起来非常不方便；其次，用户A的密码是以明文方式传送到服务器S的，密码容易被公司内部的其它用户所窃听。方案三：用户A登录时自动将自己的名字发到服务器S，服务器S收到后生成一身份识别卡后用用户A的密码先加密（别忘记了服务器S上有所有用户和服务的密码），然后发回给用户A。用户A收到后可以用他自己的密码解密，之后他要申请任何服务时，只需要用识别卡向服务器S申请就行，不用再次输入密码。这个方案正好解决了解决方案二的两个缺陷，一来用户A无需每次请求服务都输入一次密码，二来他的密码从不以明文的方式传送到其它服务器。可是，这个方案还是有缺陷：假设用户A用用户X的工作站登录，然后向服务器请求了一些个人文件，如果用户X有个后台程序偷偷收集用户A的那些服务券，那他就可以假冒用户A向服务器提出服务了。方案四：解决的方法就是“时限”正如折扣券一样，服务券也应该有一个有效期，验证服务器在生成服务券时可以增加一些内容：用户A的名字，用户A申请时所登录的工作站IP，用户A请求的服务B的名字，时间戳，使用期限。那么，使用期限规定在多长时间后呢？一般上班时间为8小时，我们就设置成8小时。8小时一过，合法的用户A也要向服务器S重新申请新的服务券（不是身份识别卡，所以无需重新登录），这听起来是可以接受的。可是，这个方案还是有缺陷：在上面举的例子中，只要在使用期限没到之前，用户X照样可以假冒用户A向服务器B提出服务。我们可以修改规则：服务券每次只能使用一次，这样一来就算被非法用户复制了也没关系。可是合法用户现在每次使用服务就要重新请求新的服务券，看来安全和方便无法兼得啊。方案五：初看起来方案四的缺陷似乎无法解决，我们先来分析一下服务器B是怎样验证用户发送过来的服务券的。上面说了，服务券上有用户A的名字，用户A申请时所登录的工作站IP，用户A请求的服务B的名字，还有时间戳和使用期限；而且在方案二里也说过，这张服务券是用服务器B的密码加密过的。如果服务器B能用它自己的密码解密，这说明服务券不是伪造的。可是在方案四里举的用户X偷偷复制用户A服务券的例子里，服务器B无法通过对比服务券判断出这是一个非法请求。问题就在于用户A和服务器B之间并没有任何共享的秘密，如果验证服务器S在发服务券给用户A时，顺便生成一服务券密码P，同时发给用户A和服务B。具体的做法可以是这样的：当验证服务器S收到用户A对服务B的请求时，先生成一服务券密码P，然后：1）将服务券密码P和用服务器B密码加密过后的服务券：用户A的名字，用户A申请时所登录的工作站IP，用户A请求的服务B的名字，时间戳，使用期限一起发给用户A。2）将用服务器B密码加密过后的服务券：用户A的名字，用户A申请时所登录的工作站IP，用户A请求的服务B的名字，时间戳，使用期限，服务券密码P发给服务器B。服务器B收到从验证服务器S发来的服务券后，可以用它自己的密码对所有服务券解密后备用。用户A收到服务券后，就可以这样向服务器B提出请求了：先把用户A的名字，用户A申请时所登录的工作站IP一起用服务券密码P加密生成一验证券，再将它和服务券一起发给服务器B。验证券就是看门狗的第二个头。服务器B收到来自用户的验证券+服务券后，首先用它自己的密码解开服务券，现检查时间戳和使用期限。如果没问题的话，就从它解密过的服务券里找出相对应的那张，得到相对应的服务券密码P解开验证券，得到验证券里藏着的用户A的名字，用户A申请时所登录的工作站IP，再去和服务券里的信息匹配，这样就能验证服务票的发送者是不是真的是真实的所有者了。大家一定会觉得这种加密策略简直比那几个逃脱游戏还BT嘛，不过为了达到安全的目的，多BT的手段都可以用。可是，这个方案还是有缺陷：只要在使用期限没到之前，如果用户X同时偷到用户A的验证券和服务券的话，他还是可以假冒用户A向服务器B提出服务。方案六：我们虽然不能限制每张服务券只能使用一次（因为很不方便，见方案四的说明），但是我们能限制每个验证券只能使用一次不过，如果服务器S在发服务券和服务券密码P给用户A的过程中，被用户X截取了，那么他就可以仿造新的有效的用户A的检验器骗过服务器B。解决的方法就是让我们更BT一些吧：检验服务器S将服务券密码P和用服务器B密码加密过后的服务券放在一起，再用用户A的密码加密后才发给用户A。这样的话，就算用户X在传输过程中截取了，没有用户A的密码也没用。我们上面考虑的都是怎样使服务不会让非法用户使用，不过，我们也要考虑怎样使用户的请求不会被非法服务截取。比如说用户A发送一份文件到打印服务器B打印，用户X可以在另外一台打印服务器Y做了手脚，也取得一份复印。改进的方法就是双重验证：当服务器B收到用户A发来的服务券后，并不立即执行服务，而是先生成一确认券：，再用服务券密码P加密后发给用户A。这样用户A也可以验证服务器B的身份，通过后再发送指令让服务器B完成请求。确认券就是看门狗的第三个头。现在我们可以再来看看上面给出的公式了：A - S: A, B用户A向验证服务器S发送信息：A请求服务BS - A: TS, L, K