代码签名和认证

• Token认证签名加密
• WHQL认证和代码签名
• JVM 代码签名和认证
• 一个新的自认证聚合签名方案
• vbs xmldom初次实战获取QQ签名的代码

这种方式就像这样：你为某个公司介绍一个人，而那个公司不知道是好人还是坏人（就是说不知道是安全代码还是恶意代码），你怎么办呢？你就给那个公司寄了一个箱子，箱子里面装的是那个人的指纹（就是用私钥对散列值加密），而箱子是被一把锁（就是你的私钥）封闭了的，而这个人到了那个公司之后，那个公司首先用你给他的公钥（就是那个把锁的钥匙）解开那个箱子，然后取出箱子里的指纹（就是用公钥将签名值进行解密后的散列值），如果这个指纹跟那个人的指纹（就是原class文件的散列值）相符，那么这个公司就可以确定这个人是你推荐来的，你为这个人担保了的，所以这个人是个好人（意思就是安全的代码）！如果不相符，那么就拒绝这个人（恶意代码）！整个过程这个箱子是封闭了的，而且只有这个公司才能打开这个箱子查看指纹。但是这种方式不是绝对安全的，试想一下，我是一个黑客，我可以从三方面下手，第一，我的恶意代码产生和安全代码相同的散列值，这种方式不切实际，因为这就像破解密码一样。第二，盗取你的私钥，如果我得到你的私钥，那么我为自己恶意代码签名，就可以为所欲为，但是这种方法就像盗取别人的密码一样。第三，将别人的公钥替换成自己的公钥，这种方式很容易做到，如果某个人的公钥是从网上发布的，那么别人在下载这个公钥之前我把它替换成自己的公钥，这样的话，我再用自己的私钥为自己的恶意代码签名（私钥和公钥是成对的），那么下载公钥的人却误认为是解密后的散列值与原始class散列值相同（其实他只是用我的公钥解密我的私钥而已，所以我编写什么代码也可以蒙混过关），我就利用了用户对别人的信任来侵入他们的系统了。

所以从上面就可以看出，公钥发布成了一个问题，其实公钥发布的困难本身也是一个认证问题。试想一下，“我怎么确认这个代码是不是恶意代码”和“我怎么确认这个公钥是不是假公钥”属于同样的问题，基于这种思考，建立了许过证书机构来为这些公钥做担保。例如，你可以到一个证书机构去，给出你的信任证明（例如出生证明、驾驶证、护照等等）以及你的公钥。一旦确认你是真的如你自己所说的那个人，证书机构将会用证书机构的私钥对你的公钥进行前面，最终得到的数字序列被称为证书。这样，你就可以发布你的证书了，而不是你的公钥了。这种方式只是相对好了些，因为要替换公钥的话必须还要得到证书机构的私钥。