用 Kerberos 为 J2ME 应用程序上锁，第 3 部分: 建立与电子银行的安全通信（下）

核心提示： 注意在 第一篇文章中的清单 3 和图 5 中，纯文本格式的 Authenticator 结构由以下字段组成（省略最后一个字段，用 Kerberos 为 J2ME 应用程序上锁，第 3 部分: 建立与电子银行的安全通信（下）(8)，它是不需要的）： authenticator-vnocrealcn

注意在 第一篇文章中的清单 3 和图 5 中，纯文本格式的 Authenticator 结构由以下字段组成（省略最后一个字段，它是不需要的）：

authenticator-vno

creal

cname

cksum

cusec

ctime

subkey

seq-number

在解释 第一篇文章的图 5时，我已经介绍了每一个字段的意义。

authenticator-vno 字段与 pvno 字段完全相同（本节前面讨论了 vno 字节数组，它包含特定于上下文的标签号 0 且带值为 5 的 INTEGER ）。所以我重用了在 authenticator_vno 字段中使用的同一个字节数组。

现在该生成 crealm 字段了，它类似于我在 第二篇 文章“生成请求正文”一节中介绍的 realm 字段。同样，在那一节也介绍了 PrincipalName 类型的 cname 字段。在这里我就不介绍 crealm 和 cname 字段的生成细节了。

下一项任务是生成 cksum 字段，它是 Checksum 类型。服务票据请求中的 cksum 字段的作用是加密结合 authenticator 与一些应用程序数据。注意以下三点：

authenticator 结构包含 cksum 字段。

cksum 字段包含一些应用程序数据的加密哈希值。

整个 authenticator 结构（包括 cksum 字段）是用一个密钥加密的。

只要在 authenticator 中的 cksum 字段与对应用程序数据的加密 checksum 相匹配，就证明生成 authenticator 和应用程序数据的客户机拥有密钥。

调用 getAuthenticationHeader() 方法的应用程序（通过调用 getChecksumBytes() 方法）生成 Checksum 结构，并将 Checksum 字节数组作为 checksumBytes 参数的值传递给 getAuthenticationHeader() 方法。

结果， checksumBytes 参数中就有了 Checksum 结构。只需要将 checksumBytes 包装到特定于上下文的标签号 3 中（这是 authenticator 结构中 cksum 字段的标签号）。