安全--代码签名和认证

代码签名和认证 Java安全模型很重要的一点就是它能支持认证，这是在Java 1.1的java.security包及其子包中引入的特性。
认证功能加强了用户的能力，使用户能通过实现一个沙箱来建立多种安全策略， 这个沙箱可以依赖于为这个代码提供担保的对象来改变。
认证可以使用户确认，由某些团体担保的一些class文件是值得信任的，并且这些class文件在到达用户虚拟机的途中没有被改变。 这样，如果用户在一定程度上信任这个为代码作担保的团队，也就可以在一定程度上简化沙箱对这段代码实施的限制。 可以对由不同团体签名的代码建立不同的安全限制。
要对一段代码作担保或签名，必须首先生成一个公钥/私钥对。用户保管私钥，把公钥公开。 至少，应该把公钥给那些要在你的签名上建立安全策略的人。  一旦拥有了一个公钥/私钥对，就必须要签名class文件和其他文件放到一个jar文件中，然后使用一个工具对整个jar文件签名。
签名工具将首先对jar文件的内容进行单向散列计算，以产生一个散列。 然后签名工具将用私钥对这个散列进行签名，并且将经过签名后的散列加到jar文件的末尾。 这个签名后的散列代表了你对这个jar文件内容的数字签名。
当发布这个包含签名散列的jar文件时，那些持有你的公钥的人将对jar文件验证两件事： 这个jar文件确实是你签名的，并且在你签名后这个jar文件没有做过任何改动。
数字签名过程的第一步 是一个单向的散列计算，它输入大量的数据，但产生少量的数据，成为散列。 在这个jar文件的例子中，这个计算的大量输入就是组成这个jar文件内容的字节流。 这个单向散列计算是“单向”，在只给出散列的情况下，这个散列值不能包含足够的输入的信息，因此不能从散列重新生成原输入。 这个计算是单向的，从大到小，从输入到散列。
散列也被成为消息文摘，它相当于一种输入“指纹”。 虽然不同的输入可能会产生相同的散列，但实际情况下，一个散列足矣代表了产生它的输入。 一个散列也被用于识别单向散列算法产生这个散列的输入。 在认证过程中，散列被用于验证某个输入是否和产生这个原始散列的输入相同，验证这个输入在到达目的地途中有没有被改动。
因为不可能仅仅用散列重构原输入，一个散列仅在可以得到原输入时才有用，因此，必须将输入和散列一起传输。 对它们本身来说，输入和散列的组合并不安全，为了防止这种情况的发生，就必须在发生散列前，用私钥对它进行加密。 只加密散列而不是对整个jar进行加密，这是因为用私钥进行加密是一个相当费事的过程，一般来说，从jar文件中计算、产生一个单向散列，并对这个散列用私钥进行加密，要比对整个jar文件用私钥进行加密来得快。 只有当黑客拥有你的私钥时，才能同时替换输入和加密后的散列，因此要小心保存私钥。
任何用你的私钥加密的东西 都可以用你的公钥解密。 公钥/私钥对具有这种特点，在仅给出公钥的情况下，想要产生私钥是非常困难的。

因为单向散列算法是从大量数据(输入)中产生少量数据(消息摘要或者散列)，所以不同的输入可能产生相同的散列。 实际情况中，普遍采用的是64位或者128位的散列，通常认为这个长度已经足够了。
在产生散列值并用私钥对它签名后，随后将加密后的散列值加到同一个jar文件中，这个jar还包含了最初产生这个散列 的文件。 一个经签名的jar文件，包含了输入---你要担保的class文件和数据文件---以及用你的私钥加密过的散列值(由输入产生)。 加密的散列代表了你对同一个jar文件中的类和数据文件的数字签名，
要认证一个已签名的jar文件，接受者必须用公钥对签名散列进行解密，得到的结果应该和从jar文件计算而得到的散列值相等。 为了验证一个jar文件在签名后未被改动，接受者只要对jar文件的内容实施单向散列算法，就像在签名过程中所作的那样。 如果得到的散列值和加密的散列值匹配，那么接受者就可以推断，你确实为jar文件进行了担保，而且这个jar文件的内容在你加上你的签名后没有被改动过。这个jar文件中包含的代码就可以被放在一个不严格的沙箱中，这个沙箱信任你的签名。

证书机构将用证书机构的私钥对某些人的公钥进行签名，最终得到的数字序列被称为证书。