Core Javatrade; Volume II–Advanced Features

When Java technology first appeared on the scene, the excitement was not about a well-crafted programming language but about the possibility of safely executing applets that are delivered over the Internet (see Volume I, Chapter 10 for more information about applets). Obviously, delivering executable applets is practical only when the recipients are sure that the code cant wreak havoc on their machines. For this reason, security was and is a major concern of both the designers and the users of Java technology. This means that unlike other languages and systems, where security was implemented as an afterthought or a reaction to break-ins, security mechanisms are an integral part of Java technology.

Three mechanisms help ensure safety:

bull; Language design features (bounds checking on arrays, no unchecked type conversions, no pointer arithmetic, and so on).

bull; An access control mechanism that controls what the code can do (such as file access, network access, and so on).

bull; Code signing, whereby code authors can use standard cryptographic algorithms to authenticate Java code. Then, the users of the code can determine exactly who created the code and whether the code has been altered after it was signed.

Below, youll see the cryptographic algorithms supplied in the java.security package, which allow for code signing and user authentication.

As we said earlier, applets were what started the craze over the Java platform. In practice, people discovered that although they could write animated applets like the famous 'nervous text' applet, applets could not do a whole lot of useful stuff in the JDK 1.0 security model. For example, because applets under JDK 1.0 were so closely supervised, they couldnt do much good on a corporate intranet, even though relatively little risk attaches to executing an applet from your companys secure intranet. It quickly became clear to Sun that for applets to become truly useful, it was important for users to be able to assign different levels of security, depending on where the applet originated. If an applet comes from a trusted supplier and it has not been tampered with, the user of that applet can then decide whether to give the applet more privileges.

To give more trust to an applet, we need to know two things:

bull; Where did the applet come from?

bull; Was the code corrupted in transit?

In the past 50 years, mathematicians and computer scientists have developed sophisticated algorithms for ensuring the integrity of data and for electronic signatures. The java.security package contains implementations of many of these algorithms. Fortunately, you dont need to understand the underlying mathematics to use the algorithms in the java.security package. In the next sections, we show you how message digests can detect changes in data files and how digital signatures can prove the identity of the signer.

A message digest is a digital fingerprint of a block of data. For example, the so-called SHA1 (secure hash algorithm #1) condenses any data block, no matter how long, into a sequence of 160 bits (20 bytes). As with real fingerprints, one hopes that no two messages have the same SHA1 fingerprint. Of course, that cannot be true—there are only 2¹⁶⁰ SHA1 fingerprints, so there must be some messages with the same fingerprint. But 2¹⁶⁰ is so large that the probability of duplication occurring is negligible. How negligible? According to James Walsh in True Odds: How Risks Affect Your Everyday Life (Merritt Publishing 1996), the chance that you will die from being struck by lightning is about one in 30,000. Now, think of nine other people, for example, your nine least favorite managers or professors. The chance that you and all of them will die from lightning strikes is higher than that of a forged message having the same SHA1 fingerprint as the original. (Of course, more than ten people, none of whom you are likely to know, will die from lightning strikes. However, we are talking about the far slimmer chance that your particular choice of people will be wiped out.)

A message digest has two essential properties:

bull; If one bit or several bits of the data are changed, then the message digest also changes.

bull; A forger who is in possession of a given message cannot construct a fake message that has the same message digest as the original.

The second property is again a matter of probabilities, of course. Consider the following message by the billionaire father:'Upon my death, my property shall be divided equally among my children; however, my son George shall receive nothing.'

That message has an SHA1 fingerprint of

2D 8B 35 F3 BF 49 CD B1 94 04 E0 66 21 2B 5E 57 70 49 E1 7E

The distrustful father has deposited the message with one attorney and the fingerprint with another. Now, suppose George can bribe the lawyer holding the message. He wants to change the message so that Bill gets nothing. Of course, that changes the fingerprint to a completely different bit pattern:

2A 33 0B 4B B3 FE CC 1C 9D 5C 01 A7 09 51 0B 49 AC 8F 98 92

Can George find some other wording that matches the fingerprint? If he had been the proud owner of a billion computers from the time the Earth was formed, each computing a million messages a second, he would not yet have found a message he could substitute.

A number of algorithms have been designed to compute these message digests. The two best-known are SHA1, the secure hash algorithm developed by the National Institute of Standards and Technology, and MD5, an algorithm invented by Ronald Rivest of MIT. Both algorithms scramble the bits of a message in ingenious ways. For details about these algorithms, see, for example, Cryptography and Network Security, 4th ed., by William Stallings (Prentice Hall 2005). Note that recently, subtle regularities have been

剩余内容已隐藏，支付完成后下载完整资料

---

Java核心技术 卷Ⅱ高级特性

当Java技术刚刚问世时，令人激动的并不是因为它是一个设计完美的编程语言，而是因为它能够安全地运行通过因特网传播的各种applet。很显然，只有当用户确信applet的代码不会破坏他的计算机时，用户才会接受在网上传播的可执行的applet。正因为如此，无论过去还是现在，安全都是设计人员和Java技术使用者所关心的一个重大问题。这就意味着，Java技术与其他的语言和系统有所不同，在那些语言和系统中安全是事后才想到要去实现的，或者仅仅是对破坏的一种应对措施，而对Java技术来说，安全机制是一个不可分割的组成部分。

Java技术提供了以下三种确保安全的机制：

(1)语言设计特性（对数组的边界进行检查，无不检查类型的转换，无指针算法等）。

(2)访问控制机制，用于控制代码能够执行的功能（比如文件访问，网络访问等）。

(3) 代码签名，利用该特性，代码的作者就能够用标准的加密算法来表明Java代码的身份。这样，该代码的使用者就能够准确地知道谁创建了该代码，以及代码被标识后是否被修改过。

下面，我们要介绍java.security包提供的加密算法，用来进行代码的标识和用户身份认证。

正如我们前面所说，applet 是在Java平台上开始流行起来的。实际上，人们发现尽管他们可以编写像著名的“nervous text”那样栩栩如生的applet，但是在JDK1.0安全模式下无法发挥其一整套非常有用的作用。例如，由于JDK1.0下的applet要受到严密的监督，因此，即使applet在公司安全内部网上运行时的风险相对较小，applet也无法在企业内部网上发挥很大的作用。Sun公司很快就认识到，要使applet真正变得非常有用，用户必须可以根据applet的来源为其分配不同的安全级别。如果applet来自值得信赖的提供商，并且没有被篡改过，那么applet的用户就可以决定是否给applet授予更多的运行特权。

如果要给予applet更多的信赖，你必须知道下面两件事：

(1)applet来自哪里？

(2)在传输过程中代码是否被破坏？

在过去的50年里，数学家和技术机科学家已经开发出各种各样成熟的算法，用于确保数据和电子签名的完整性，在java.security包中包含了许多这些算法的实现。在下面几节，我们将要介绍消息摘要是如何检测数据文件中的变化的，以及数字签名是如何证明签名者的身份的。

消息摘要是数据块的数字指纹。例如，所谓的SHA1（安全散列算法#1）可将任何数据块，无论其数据有多长，都压缩为160位（20字节）的序列。与真实的指纹一样，人们希望任何两条消息都不会有相同的SHA1指纹。当然这是不可能的—因为只存在2¹⁶⁰ 个SHA1指纹，所有肯定会有某些消息具有相同的指纹。因为2¹⁶⁰ 是一个很大的数字，所以存在重复指纹的可能性微乎其微，那么这种重复的可能性到底小到什么程度呢？根据James Walsh在他的《True Odds:How Risks Affect Your Everyday Life》,Merritt Publishing出版社1996年出版，一书中所阐述的，你和他们所有的人都死于雷击的概率，比伪造的消息与原来消息具有相同的SHA1指纹的概率还要高。（当然，可能有你不认识的其他10个以上的人会死于雷击，但这里我们讨论的是你选择的特定的人的死亡概率）。

消息摘要具有两个基本属性：

(1)如果数据的1位或者几位改变了，那么消息摘要也将改变。

(2）拥有给定消息的伪造者不能创建与原消息具有相同摘要的假消息。

当然，第二个属性又是一个概率问题。让我们来看看下面这位亿万富翁下的遗嘱：“我死了之后，我的财产将由我的孩子平分，但是，我的儿子George应该拿不到一个子。”

这份遗嘱的SHA1指纹为：

2D 8B 35 F3 BF 49 CD B1 94 04 E0 66 21 2B 5E 57 70 49 E1 7E

这位有疑心病的父亲将这份遗嘱交给一位律师保存，而将指纹交给另一位律师保存。现在，假设George能够贿赂那位保存遗嘱的律师，他想修改这份遗嘱，使得Bill一无所得。当然，这需要将原指纹改为下面这样完全不同的位模式：

2A 33 0B 4B B3 FE CC 1C 9D 5C 01 A7 09 51 0B 49 AC 8F 98 92

那么George能够找到与该指纹相匹配的其他文字吗？如果从地球形成之时，他就很自豪地拥有10亿台计算机，每台计算机每秒钟处理一百万条信息，他依然无法找到一个能够替换的遗嘱。

人们已经设计出大量的算法，用于计算这些消息摘要，其中最著名的两种算法是SHAI和MD5。SHAI是由美国国家标准和技术学会开发的加密散列算法，MD5是由麻省理工学院的Ronald Rivest发明的算法。这两种算法都使用了独特巧妙的方法对消息中的各个位进行扰乱。如果要了解这些方法的详细信息，请参阅William Stallings撰写的《Cryptography and Network Security》一书，该书由Prentice Hall出版社于2005年出版口值得注意的是，最近人们在这两种算法中发现了某些微妙的规律性，因此许多密码人员建议最好避免使用MD5，而应该使用SHA1算法，直到有更强的加密算法出现。（查看http://www.rsa.com/rsalabs/node.asp?id=2834以了解更多的信息）。

Java编程语言已经实现了SHA1和MD5。MessageDigest类是用于创建封装了指纹算法的对象的“工厂”，它的静态方法getInstance返回继承了MessageDigest类的某个类的对象。这意味着MessageDigest类能够承担下面的双重职责：

（1）作为一个工厂类。

（2）作为所有消息摘要算法的超类。

例如，下面是如何获取一个能够计算SHA指纹的对象的方法：

MessageDigest alg = MessageDigest.getInstance(“SHA-1”)；

（如果要获取计算MD5的对象，请使用字符串“MD5”作为getInstance的参数。）

当你已经获取MessageDigest对象之后，通过反复调用update方法，将信息中的所有字节提供给该对象。例如，下面的代码将文件中的所有字节传给上面建立的alg对象，以执行指纹算法：

InputStream in=hellip;.

int ch；

while((ch=in.read())!=-1)

alg.updat((byte) ch)；

另外，如果这些字节存放在一个数组中，那就可以一次完成整个数组的更新：

byte[] bytes =．．．；

alg.update(bytes)；

当完成上述操作后，调用digest方法。该方法填充输入信息—指纹算法需要的—并且进行相应的计算，然后以字节数组的形式返回消息摘要。

byte[] hash=alg.digest()；

程序清单9-15中的程序计算了一个消息摘要，既可以用SHA，也可以使用MD5来计算。可以从文件加载需要计算摘要的数据，也可以直接将信息输入文本区域。图9-11显示了该应用程序的画面。

消息签名

在上一节中，我们介绍了如何计算原始消息的消息摘要和指纹的方法。如果消息改变了，那么改变后的消息的指纹与原消息的指纹将不匹配。如果消息和它的指纹是分开传送的，那么接收者就可以检查消息是否被篡改过。但是，如果消息和指纹同时被截获了，对消息进行修改，再重新计算指纹，这是一件很容易的事情。毕竟，消息摘要算法是公开的，不需要使用任何密钥。在这种情况下，假消息和新指纹的接收者永远不会知道消息已经被篡改。数字签名解决了这个问题。

为了了解数字签名的工作原理，我们需要解释关于公共密钥加密技术领域中的几个概念。公共密钥加密技术是基于公共密钥和私有密钥这个两个基本概念的。它的设计思想是你可以将公共密钥告诉世界上的任何人，但是，只有自己才拥有私有密钥，重要的是你要保护你的私有密钥，不将它泄漏给其他任何入。这些密钥之间存在一定的数学关系，但是这种关系的具体性质对于实际的编程来说并不重要(如果你有兴趣，可以参阅http://www.cacr.math.uwaterloo.ca/hac/站点上的《The Handbook of Applied Cryptography》 一书)。

密钥非常长，而且很复杂。例如，下面是一对匹配的数字签名算法(DSA)公共密钥和私有密钥。

公共密钥：

p: fca682ce8e12caba26efccf7ll0e526db078b05e6ecbcdleb4a208f3ae1617ae0lf35b9la47e6df63413c5e12ed0899bcd132acd50d9915lbdc43ee737592el7

q: 962eddcc369cba8ebb260ee6b6a126d9346e38c5

g:67847lb27a9cf44ee9la49c5147dbla9aaf244f05a434d648693ld2d1427lb9e35030b7lfd73da179069b32e2935630elc2062354d0da20a6c416e50be794ca4

y：

c0b6e67b4ac098ebla32c5f8c4clfee7e6fb9d832532e27d0bdab9ca2d2a8123ce5a8018b816la6048efadd040b927281ddb22cb9bc4df596d7de4dlb977dS0

私有密钥：

p：

fca682ce8e12caba26efccf7ll0e526db078b05edecbcdleb4a208f3ae1617ae0lf35b9la47e6df63413c5e12ed0899bcd132acd50d9915lbdc43ee737592e17

q: 962eddcc369cba8ebb260ee6b6a126d9346e38c5

g：

67847lb27a9cf44ee9la49c5147dbla9aaf244f05a434d648693ld2d1427lb9e35030b7lfd73da179069b32e2935630elc2062354d0da20a6c416e50be794ca4

x: 146c09f881656cc6c5lf27ea6c3a9lb85edld70a

在现实中，几乎不可能用一个密钥去推算出另一个密钥。也就是说，即使每个人都知道你的公共密钥，不管他们拥有多少计算资源，他们一辈子也无法计算出你的私有密钥。

任何人都无法根据公共密钥来推算私有密钥，这似乎让人难以置信。但是时至今日，还没有人能够找到一种算法，来为现在常用的加密算法进行这种推算。如果密钥足够长，那么要是使用穷举法—也就是直按试验所有可能的密钥—所需要的计算机将比用太阳系中的所有原子来制造的计算机还要多，而且还得花费数千年的时间。当然，可能会有人提出比穷举更灵活的计算密钥的算法。例如，RSA算法（该加密算法由Rivest, Shamir和Adleman发明）就利用了对数值巨大的数字进行因子分解的困难性。在最近20年里，许多优秀的数学家都在尝试提出好的因子分解算法，但是迄今为止都没有成功。据此，大多数密码学者认为，拥有2000位或者更多位“模数”的密钥目前是完全安全的，可以抵御任何攻击。DSA被认为具有类似的安全性。

图9-12展示了这项工作的处理过程。

假设Alice想要给Bob发送一个消息，Bob想知道该消息是否来自Alice，而不是冒名顶替者。Alice写好了消息，并且用她的私有密钥对该消息摘要签名。 Bob得到了她的公共密钥的拷贝，然后Bob用公共密钥对该签名进行校验。如果通过了校验，则Bob可以确认以下两个事实：

（1)原始消息没有被篡改过。

（2)该消息是由Alice签名的，她是私有密钥的持有者，该私有密钥就是Bob

与她用于校验的公共密钥相匹配的密钥。

你可以看到私有密钥的安全性为什么是最重要的。如果某个人偷了Alice的私有密钥，或者政府要求她交出私有密钥，那么她就麻烦了。小偷或者政府代表就可以假扮她的身份来发送消息和资金转账指令等等，而其他人则会相信这些消息确实来自于Alice。

X.509证书格式

为了利用公共密钥这种密码系统，必须将公共密钥分发出去。最通用的一种签名证书格式称为X.509格式。X.509格式的证书被VeriSign、微软、网景和其他许多公司广泛应用于对电子邮件消息进行签名，对程序代码进行认证，以及对许多其他类型的数据进行认证等等。 X.509标准是由国际电话标准机构，即国际电报电话咨询委员会(CCITT)提出的用于目录服务的X.500系列建议的组成部分。

X.509证书的具体结构是用一种形式化表示来描述的，称为“抽象语法表示法#1”(abstract syntax notation)即ASN.1。图9-13显示了第3版X.509格式的ASN.1定义。虽然具体的语法对我们并不重要，但是你可以看到，ASN.1为证书文件的结构给出了精确的定义。“基本编码规则”(basic encoding rules)，即BER，精确地描述了如何将该结构保存为二迸制文件。也就是说，BER描述了如何对整数、字符串、位串以及诸如SEQUENCE、CHOICE和O

剩余内容已隐藏，支付完成后下载完整资料

---

资料编号：[146632]，资料为PDF文档或Word文档，PDF文档可免费转换为Word