再用客户端私钥KUS解密 Ekup(R)，即：
　　Dkus[Ekup(R)]=R’，
　　然后再用公开的单向散列函数H（必须与AAA Server使用的H相同），求 R ′的散列值H（R ′）。如果在传输过程中R被篡改过，即R ′≠R，那么根据散列函数的性质，必然有：H（R ′）≠H（R）， 从而发现R被修改过这一事实。
　　如果上面的操作证明R未被修改，那么客户端接下来的工作是设法将解密得到的R ′不被篡改地传回AAA Server，以便AAA Server进行鉴别。为了防止在将R ′传回给AAA Server的过程中，被黑客捕获并篡改，使得合法用户不能通过认证。在回传R ′时，先对R ′施以单向散列函数H，得到R ′的一个散列值H（R ′）。然后使用用户的私钥KUS对H（R ′）进行加密（数字签名），最后将R ′和加密后的H（R ′）一起，即R’+Ekus[H(R’)]回传给AAA Server。这里R′可以明文传输，无需加密，因为R是随机数，每次都不一样，黑客即使获得R′也不能对认证过程构成威胁。
　　AAA Server收到R’+Ekus[H(R’)]后，验证过程如下：
　　首先验证R ′是否等于R。 如果R ′＝R，说明该证书确实为其出示者所有，对用户的认证获得通过。
　　如果R ′≠R，有两种可能，即要么用户提供的证书是假的，要么R ′在传输过程被人篡改过。要检查R ′是否被修改过，AAA Server只需验证用户的数字签名即可：
　　如果R ′被篡改为R″（R″≠ R ′），则必然有H（R″）≠H（ R ′），从而可以发现R ′在传输过程中被修改过。
　　如果经过前面验证，R ′在传输过程中没有被修改，信捷职称论文写作发表网，且R ′≠R，这说明用户所出示的数字证书非法，用户认证失败。
　　至此， AAA Server对客户端认证完成。反方向的客户端对AAA Server的认证类似，不再详述。
　　当双向认证完成后（事实上，可以是客户端被认证合法之后），AAA Server向SMS（Subscriber Management System，用户管理系统）发送用户通过认证，并请求该用户的业务信息。SMS收到请求后，查找该用户的业务信息，并发送给AAA Server。AAA Server据此对该用户授权、计费。
　　
　　4 方案性能分析
　　
　　本认证方案采用了单向散列函数、非对称密码体制、数字证书、数字签名等信息安全技术。认证服务器无需存储用户公钥，也不需要查找相应数据库，处理速度快。
　　(1)有效性（Validity）：在本认证方案过程中，要求用户出示了由移动运营商证书服务器颁发的数字证书，并对证书进行了三项验证，确保证书的有效性（为移动运营商证书服务器所颁发）、完整性（未被修改过）和真实性（确实为该用户所有）得到验证。在AAA Server方，我们认为没有必要向客户端出示其证书。客户端知道合法的AAA Server的公钥，只需验证自称是AAA Server的一方拥有该公钥对应的私钥即可，因为世界上有且仅有合法的AAA Server知道该私钥。
　　(2)完整性（Integrity）：在认证消息传输过程中，我们始终坚持了消息可靠传输这一原则，对认证消息采取了保护措施。一旦认证消息在传输过程中被修改，消息到达对方时将被发现。
　　不可否认性（Non-repudiation）：本方案中所有认证消息都采用了发送方数字签名，使得发送方对自己发送的消息不可否认。
　　可行性（Feasibility ）：本认证方案采用的单向散列函数、非对称密码体制、数字证书等信息安全技术经过多年发展，已经比较成熟。单向散列函数有MD2、MD4、MD5、SHA系列、HAVAL-128以及RIPEMD等，其中MD4目前被认为不安全。非对称密码体制中最成功的是RSA。值得一提的是与RSA算法相关的基本专利已于2000年9月到期，这直接关系到系统成本。另外，本方案采用的数字证书是自己颁发的，移动运营商的证书服务器具有自签名的顶级证书，无需借助第三方证书机构。
　　
　　5 结束语
　　
　　彩信丰富人们的生活，手机银行，手机炒股……各种网络应用在移动网络中产生，通信安全显的很重要。通过数字签名技术来解决手机彩信通信安全是一种切实可行的方案，非对称的加密体制为方案的实现提供了可能性，在基于J2ME的开发平台下实现，使得具有很强的可移植性，为手机彩信提供安全保障。
　　
　　参考文献：
　　[1]赵泽茂.数字签名理论.北京:科学出版社,2007.
　　[4]杨世平,李祥.一种广播多重(t, n)门限数字签名方案[J].计算机应用研究,2006.
　　[2]Andrew Nash, William Duane, Celia Joseph, Derek Brink: PKI: Implementing and Managing E-Security, McGraw-Hill Companies,2001.
　　[3]IETF,RFC2246,The TLS Protocol Version 1.0, ?number=2246, January 1999.
　　[4]Shimshon Berkovits, Santosh Chokhani, et al. Public Key Infrastructure Study(final version) [M]. Nation Institute of Standards and Technology,2005.