浅论手机彩信签名研究

论文关键词：手机彩信通信；数字签名；彩信认证；双向认证；J2ME

论文摘要： 本文探讨一种基于非对称密码体制、单向散列函数、数字证书和数字签名的手机彩信通信接入双向认证方案。在本方案中，认证服务器无需存储和查找客户端公钥，且移动运营商具有自签名的顶级证书服务器，无需借助第三方颁发证书。最后对本方案做了简要的性能分析。

1 引言

移动通信技术发展日新月异，3G，E3G，4G这些标志通信技术里程碑的名词。通过手机彩信功能，现在可以传输文字，图片，音乐和视频等多媒体信息。彩信丰富了我们的日常生活，与此同时彩信中夹杂病毒和一些不良信息的现象不段出现。通信安全问题已成为制约移动网络应用的一个瓶颈，并且随着移动通信网络的迅猛发展，日益变得突出。借鉴互联网领域的数字签名技术，本文探讨通过非对称密钥体制来实现手机彩信的通信安全。

2 非对称密钥体制

有对称和非对称两种密钥体制。在对称密钥系统中，加密和解密采用相同的密钥。因为加解密钥相同，需要通信的双方必须选择和保存他们共同的密钥，各方必须信任对方不会将密钥泄密出去，这样就可以实现数据的机密性和完整性。对于具有n个用户的网络，需要n(n-1)/2个密钥，在用户群不是很大的情况下，对称密钥系统是有效的。但是对于大型网络，当用户群很大，分布很广时，密钥的分配和保存就成了问题。因此在移动通信中不可以采取对称密钥体制。

非对称密钥体制的基本思想是加密密钥和解密密钥不相同，由其中一个密钥推导另一个密钥在计算上是不可行的。一对彼此独立、但又在数学上彼此相关的密钥KP、KS总是一起生成，其中KP公开，称为公钥，KS保密，称为私钥。加密算法E和解密算法D是分开的。非对称密码体制的特点如下：

(1)用公钥加密的数据，只能由与其对应的私钥解密，而不能用原公钥解密；反之，用私钥加密的数据，只能由与其对应的公钥解密，而不能由原私钥解密。即，设加密算法为E，解密算法为D，KP是公钥，KS是KP对应的与私钥，明文为X，则有：Dkp[Eks(X)]可以得出明文X，而Dks[Eks(X)]则无法得出明文X。

(2)非对称钥体制不存在对称秘钥体制中的密钥分配问题和保存问题。M个用户之间相互通信只需要2M个密钥即可完成。

(3)非对称秘钥体制支持以下功能：

(4)机密性（Confidentiality）：保证非授权人员不能非法获取信息；

(5)确认（Authentication）：保证对方属于所声称的实体；

(6)数据完整性（Data integrity）：保证信息内容不被篡改；

(7)不可抵赖性（Non-repudiation）：发送者不能事后否认他发送过消息。

3 一种双向认证的方案：

首先需要在移动运营商架设一台证书服务器。证书服务器有自己的公钥KCP和私钥KCS，同时证书服务器也有一张自签名的顶级证书，以防止它的公钥被黑客替换。在用户申请开通服务时，证书服务器为用户颁发一张数字证书，并对证书进行数字签名，以防止证书内容被篡改。颁发证书的时候为用户创建了公钥KUP、私钥KUS ，其中KUS由用户保存且保密，KUP公开。

移动运营商架设一台或多台AAA Server（Authentication, Authorization, Accounting, 认证、授权、计费服务器），它负责认证、授权和计费。AAA Server有自己的私钥KSS 、公钥KSP和加密算法D、解密算法E。同时，它也拥有一张证书服务器颁发的数字证书。

用户开机或者请求某种业务时，发起相应的认证过程，即向AAA Server发送认证开始请求。AAA Server收到请求后，向用户发送证书请求，要求用户出示数字证书。然后用户将自己的数字证书发送给AAA Server。

AAA Server收到证书后，有三件事情需要证明：

(1)该数字证书是移动运营商数字证书服务器所颁发；

(2)该数字证书未被篡改过；

(3)该证书确实为出示证书者所有。

对于前面两项，AAA Server只需验证数字证书上证书服务器的数字签名即可得到证明。具体方法是用证书服务器的公钥KCP解密数字签名，然后再用公开的单向散列函数求证书的散列值，并比较二者，如果相同，验证通过，不相同，验证失败。

为了证明该证书确实为证书出示者所有，AAA Server生成一个大的随机数R，并使用用户的公钥KUP（数字证书中包含KUP ，因此服务器无需预先存储用户公钥，也无需查找数据库，这有利于加快处理速度）将R加密，得到EKup(R)。为了防止R在传输过程中被黑客截获并修改，使得合法用户得不到正确的认证。AAA Server先使用一个公开的单向散列函数H作用于R，得到H（R），然后用服务器的私钥KSS对H（R）进行加密（数字签名）。最后将 Ekup(R)+Ekss[H(R)]发送给用户。客户收到Ekup(R)+Ekss[H(r)]后，首先应该验证R在传输过程中是否被篡改过。方法如下：首先，客户端使用AAA Server的公钥KSP解开Ekss[H(R)]，即：DKsp(Ekss[H(r)])=H(R)

再用客户端私钥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, /rfc/rfc2246.txt?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.