前言

临近毕业，主要忙于手头实习跟论文了，实在觉得有点对不起各位看官了，写的少了，但是我会一直坚持下的，等论文写完以后，还是会坚持写更多的有趣的东西，在工作中，我希望也是边学习边记录，日后，这里会有更多大家意想不到的~今天S7半决赛，恭喜RNG,WE，哈哈，每个男生都有一个电竞梦，这是真哒，虽然因为学习告别好久了，但是总决赛还是会关注的哈！看我知道我习惯每天一段唠嗑哈，就是想跟大家说说话。

正文

代码签名认证这个名词不知道大家是否熟悉，那我就不管你啦，认证功能加强了用户的能力，使得用户能够通过一个 沙箱 来建立多种安全策略，这个沙箱可以依赖于为这个提供担保的对象来个改变，认证简单的说，就是某段代码有某个团队或者个人开发出来以后，由他们对代码进行签名，这是唯一的标识，任何人都无法模仿！下面会介绍怎么做到的，很强大。

通过认证的代码就是值得信任的 class文件 ，并且这些class文件在达到用户 虚拟机 的途中没有被改变，这样，我们确认安全的代码，那么我们就可以简化沙箱对它们的限制了。

那么，我们如何做到为代码担保或者签名呢？

首先必须生成一个私匙/公匙对，用户应该保管那对私匙，公匙是可以公开的，给那写些需要使用使用这段代码的用户，或者至少你需要给那些要在你的签名上建立安全策略的人，一旦拥有了一个公匙和私匙，就必须将要签名的class文件和其他的JAR文件签名，这个签名工具将会首先对JAR文件的内容进行单向散列计算，以产生一个散列，然后这个工具将用私匙对这个散列进行签名，并且将经过签名的散列加到JAR文件的末尾，这个签名后的散列代表了你对这个JAR文件内容的数字签名，当你发布这个包含签名的散列的JAR的文件是，那些持有你公匙的人就会对JAR文件验证两件事：这个JAR确保是你签名的，并且在你签名以后这个JAR就没有做过任何改动。只有这两点都确保了，才是真正安全的。

散列计算就是它输入大量的数据，但产生少量的数据，称为散列，这个JAR文件的例子中，这个计算的大量输入就是组成这个JAR文件内容的字节流。“单向”是因为只给出散列的情况下，这个散列值不包括足够的输入信息，因此不能从散列重新生成原始输入，这个计算过程是单向的，从大到小，从输入到散列。

任何要用你的私匙加密的东西都可以用你的公匙解密，私匙/公匙具有一种特点，在仅仅给出公匙的情况下，想要产生私匙是非常困难的，如果黑客无法得到你的私匙，对他来说，几乎是不可能逃过你的代码认证，他如果选择试图将原始输入替换成另一个输入，这个输入就必须和原始输入产生相同的散列值，如果黑客可以产生这样的一个可供选择的输入来达到目的（通过另一种输入得到想到的散列值），那么这个黑客就不需要你的私匙了，因为这个黑客已经可以冒名顶替你签名了，但是，这样的情况几乎是不可能实现的，付出的时间成本太大了。

对一个JAR文件数字签名

要认证一个已经签过名的JAR文件，接收者必须用公匙对签名散列进行解密，得到的结果应该和JAR文件计算而得到得散列值相等，为了验证一个JSR文件在签名后为被改动，接收者只要对JAR文件的内容实施单向散列算法，就像签名过程中所作的那样，其中要注意一点，我们不是对内容加密了，发布的内容大家度可以看得到，只是在文件末尾加了一串数字签名，如果得到得散列值和加密的散列值匹配，那么接收者就可以判定为已经经过可担保，并没有被改变过。

认证一个经过数字签名后的JAR文件

看起来似乎就解决了问题，是吧，但是技术发展必然会带来很多新的问题，看似用数学原理解决了，实际上，还是有很多漏洞，认证技术没有说明我们应该信任谁？信任到哪一地步？对一家你不是很熟悉的公司，你会完全信任它么？有过公司内部有问题，在里面出现了某些恶意的代码，是不是会发生一些不可控的东西呢？

私匙是最重要的，那谁来保管，一旦泄露，那一些都是白费？有作者还是机构保管？对于任何一个团体来书建立一个密匙管理模式来保证私匙不被泄露出去是一项具有挑战的任务。

下一节，我们会继续深入探讨这些问题。