现在客户机有了服务票据,可以将它发送到电子银行业务逻辑服务器。客户机发送图 7 中的消息到电子银行服务器。这个消息的目的是请求服务器建立与客户机的新的安全上下文。
图 7. 从 Kerberos 客户机到电子银行服务器的消息的结构
我说过本文的目的是展示基于 J2ME 的安全移动银行应用程序。我准备在服务器端使用 Generic Security Services API(GSS API,或者简称为 GSS)来为电子银行业务逻辑服务器提供安全功能。GSS 是一种一般性的高层安全 API ,它可以在像 Kerberos 这样的不同安全技术上面工作(有关 GSS 的更多内容请参阅 参考资料)。
我将在本系列的第三篇文章中讨论 GSS API 在电子银行业务逻辑服务器中的使用。现在,只要知道与 Kerberos 一样,GSS 也是一种 IETF 标准。IETF 为客户机与服务器之间相互传递的 Kerveros 消息定义了 GSS 包装器。为了在服务器端使用 GSS,我必须保证 GSS 客户机可以发出并处理 GSS 包装器。
图 7 中的外围框标记为 InitialContextToken ,它实际上是包装了从 GSS 客户机到 GSS 服务器的消息的 GSS 包装器的名字。在 InitialContextToken 包装器中,第一个字段名为 thisMech ,它定义了 GSS 作为低层安全技术使用的安全机制(在这里是 Kerveros)。
InitialContextToken 框中的第二个字段标记为 KRB_AP_REQ ,我在讨论图 5 时分析过它。回想一下前面的讨论中说过 KRB_AP_REQ 结构包装了票据。这就是为什么我可以使用这个结构包装一个服务票据并发送给电子银行服务器。我说过服务票据已经包含了子会话密钥。
清单 5 提供了 Kerberos 客户机发给电子银行业务逻辑服务器的消息的 ASN.1 类定义。您可以将图 7 中的不同字段与清单 5 中的类定义进行对照。
清单 5. 从客户机到服务器的安全上下文请求消息的 ASN.1 类定义
|
当电子银行的业务逻辑服务器收到图 7 中的消息时,它提取出服务票据并解密票据中的加密部分以得到子会话密钥。客户机已经有了同样的子会话密钥。因此,服务器和客户机可以使用这个子会话密钥彼此进行安全通信。
图 8. 电子银行对 Kerberos 客户机的响应的结构
电子银行业务逻辑服务器向客户机发回一个确认消息,如图 8 所示。下面是构成图 8 的消息的字段:
pvno:我在对图 2 的讨论中解释了这个字段。msg-type:这是具有整数值 14 的消息类型标识符。enc-part:消息的加密部分。客户机将用子会话密钥解密这个加密部分。在解密时,它将展现另一个带有以下字段的结构:ctime和cusec:我在对图 6 的讨论中解释了这些字段。subkey:这是一个服务器可能发送给客户机的可选密钥。如果服务器将这个密钥发送给客户机,那么这个密钥将被用于随后客户机与服务器之间的安全通信(取代子会话密钥)。seq-number:我在对图 5 的讨论中解释了这个字段。
清单 6 提供了电子银行对 Kerveros 客户机的响应的 ASN.1 类定义。读者可以将图 8 中显示的不同字段与清单 6 中的类定义相对照。
清单 6. 从服务器到客户机的安全上下文响应的 ASN.1 类定义
|

您现在的位置: