电子论文-基于短消息的OTA数据传输安全机制

解决方案基于短消息的OTA数据传输安全机制□郑琦（西南交通大学信息科学与技术学院，成都610031）摘要：OTA技术的应用，使得移动通信不仅能够提供语音和数据服务，还能提供更便捷的增值服务。依靠基于短消息的OTA技术，应用及内容服务商就可以很方便地不断开发出更具个性化、更贴近用户需求的服务。然而，基于短消息的OTA技术的实现，依赖于OTA平台和用户卡之间大量的数据交互，所以对数据传输安全有特定要求。针对这个问题，本文结合中国联通OTA规范，对基于短消息的OTA数据传输安全问题，及其最重要的有效性和可靠性等特性的实现进行了分析。关键字：OTA序列号MAC值一、OTA技术及OTA数据传输安全概论OTA（overtheair）空中下载技术是一项基于无线数据传输机制的技术。这项技术通过用户手机卡和OTA服务器之间的无线数据交互，实现了用户手机卡(OTA卡)内增值业务菜单的动态下载、删除与更新，方便了用户获取个性化的增值服务，如信息点播、互动娱乐、位置服务以及银行交易等。OTA的无线数据传输可以采用短消息、WAP、GPRS、CDMA1X等技术。因用户习惯于通过短消息来接收数据业务，基于短消息的无线传输方式成为了OTA技术中最为流行的方式。这种方式，也是目前2G中最为实用、投资最少的一种方式，它满足了用户对业务简单性、易用性、可下载性三方面的要求，成为了OTA技术强大的推动器。通过基于短消息的OTA空中下载技术，手机用户只要进行简单操作，即上发短信请求，就可以按照个人喜好把各种增值业务菜单下载到手机卡中，进而根据自己的意愿订制菜单中的各种增值业务。OTA技术的实现依赖于无线数据传输，而数据传输在空中接口可能会遭受信道监听、信息篡改等攻击，造成信息的泄露和丢失，因此OTA数据传输安全性的问题尤为重要。OTA数据传输安全性主要包括：数据的保密性、完整性、有效性、可靠性、不可抵赖性、可控制性和可审查性。《中国联通OTA规范》结合《GSM03.48》以及《用户手机卡的定义规则》，形成了一套完整的OTA数据传输安全机制。其中，通过序列号比对（同步控制）和MAC值校验的方式实现了数据传输安全中最重要的两个特性——有效性和可靠性。要实现基于短消息的OTA数据传输，实现OTA下载服务器与用户卡之间的数据交互，数据必须按照特定的格式组合，即参照三种报文格式：OTA业务上行报文、下行报文和远程文件更新下行报文格式。三种报文格式中都包含各种安全应用数据项，用于记录实现数据安全传输的数据值，安全应用数据项包括序列号，MAC值和随机数等。三种报文格式分别如表1、表2和表3所示。表1上行报文标识长度（字节）值说明安全应用数据卡商代码1HEX用户品牌标识2HEX卡片ICCID8HEX“00”+ICCID的后14个字符序列号5HEX随机数4HEXMAC4HEX命令数据命令类型1HEX命令长度1HEX本条短信中命令参数的长度。命令参数XHEX表2下行报文标识长度（字节）值说明安全应用数据UDHL10x02信息标识长度IEIa10x70安全头标识IEIDLa10x00信息长度CPL2后续数据长度,从CHL到最后CHL10x11安全报文头长度，从SPI到CCSPI20x02只使用第一字节bit1,bit2。0x00KIc10x00不使用加密。KID10xX1DESCBC，高4位为密钥编号TAR30xB00010OTA业务下载CNTR5参见计数器的管理PCNTR10x00参见GSM03.48。CC4使用MAC，参见MAC算法。随机数4HEX密钥分散及密钥选择用，不能加密序列号类型标识1HEX命令数据命令类型1HEX命令长度1HEX本条短信中命令参数的长度。命令参数XHEX表3远程文件更新下行报文标识长度（字节）值说明安全应用数据UDHL10X07信息标识长度IEIa10X00级联标识IEIDLa10x03级联信息长度IEDa30xXXXX01批次、短信总数、短信索引IEIb10x70安全头标识IEIDLb10x00信息长度CPL2后续数据长度,从CHL到最后CHL10x11安全报文头长度，从SPI到CCSPI20x06只使用第一字节bit1,bit2,bit3。0x00KIc10xX53DESCBCKID10xX1DESCBC，高4位为密钥编号TAR30xB0001F远程文件管理RFMCNTR5参见前向序列号的管理PCNTR10xXX参见GSM03.48。CC4使用MAC，参见MAC算法。随机数4HEX密钥分散及密钥选择用,不能加密二、OTA数据传输有效性的实现序列号比对实现数据传输有效性大量的用户不断上发短信请求，OTA下载服务器就要不断对这些请求做出下行响应。由于OTA服务器性能的限制，响应不免会出现时延，以至于用户暂时接收不到响应而重复发起同种上行请求。为了防止OTA服务器重复响应相同的上行请求，在响应前，会比对上行报文与本地OTA服务器的序列号值。同理，为防止OTA服务器发生故障或者人工误操作对用户卡端的大量重复响应，卡端也会比对下行报文中的序列号与卡端的序列号值，具体实现方法如下。序列号分为前向序列号和反向序列号，用户卡端和OTA服务器端共同维护这两种序列号。反向序列号对应于此次操作源于用户卡端发起的请求，包括所有上行短信及服务器端对该上行短信的响应。前向序列号对应于此次操作由服务器端发起的请求。（1）反向序列号用户卡端产生上行数据时，应以当前用户卡端的反向序列号值填充上行报文中的序列号数据项；在收到下行报文时（该下行数据是该上行数据的响应），若下行报文中的序列号值与当前卡端反向序列号的值相等或比当前卡端反向序列号值大1，则此次数据合法。在完成该次OTA下载过程后将卡端反向序列号的值加1。OTA下载服务器收到上行报文时（若该上行数据需要响应），当上行报文中序列号值与当前服务器反向序列号值相等，则将下行数据发送给用户卡，在发送完该次应用下载的全部下行数据后，OTA下载服务器应将当前反向序列号值加1。若上行报文中序列号值比服务器当前反向序列号的值小1，应以当前服务器反向序列号的值填入下行数据中的序列号数据项，并将下行数据发送给用户卡端，在发送完该次应用下载的全部下行数据后，OTA下载服务器应保持当前本地反向序列号的值不变。反向序列号比对流程如图1所示。图1反向序列号比对流程图（2）前向序列号服务器主动下发数据时，当下行报文中前向序列号值大于用户卡中前向序列号的值，该下行数据才可以被卡接受，用户卡端在收到该次应用下载的全部下行数据后，用下行报文中序列号的值更新卡端前向序列号的值。完成此次下行过程，将服务器端前向序列号的值加1。前向序列号比对流程如图2所示。用户卡端：产生上行数据反向序列号：A1OTA服务器反向序列号：B1A1=B1数据不合法OTA服务器：产生下行报文反向序列号：B1=A1OTA服务器：产生下行报文反向序列号：B1=A1+1A1+1=B1用户卡端：收到下行报文反向序列号：A1数据不合法A1=B1完成数据交互：用户卡端和OTA服务器反向序列号加1完成数据交互：用户卡端反向序列号加1A1=B1-1图2前向序列号比对流程图三、OTA数据传输可靠性的实现MAC值比对实现OTA数据传输的可靠性基于短消息的OTA数据传输，通过MAC值的比对，可以避免数据在传输途中遭到恶意的修改，保证上行到OTA下载服务器的数据和下行到用户卡的数据可靠性。OTA下载服务器收到上行数据后，计算该上行数据的MAC值，并与上行报文中所存放的MAC值进行比较。若两者相同，则数据在传送过程中未被修改、删除或者重组，该上行数据合法；否则，丢弃该上行数据。同理，用户卡端收到下行数据后，计算该下行数据的MAC值，并与下行报文中所存放的MAC值进行比较。若两者相同，则数据在传送过程中未被修改、删除或者重组，该下行数据合法；否则，丢弃该下行数据。特别的，当下行数据类型是远程文件更新时，要将指定的安全数据项SPI设置为1。并且在计算完MAC值后，还需要对下行数据进行加密，加密采用标准DES-CBC算法，所以，用户卡端收到下行数据后，先要对下行数据解密，再进行MAC值比对。计算MAC值，需要先得到一组安全数据值，包括：随机数，主密匙Km，会话密匙Kc。（1）随机数产生产生随机数，是为了保证此后计算MAC值的随机性与唯一性。用户卡和OTA下载服务器在上行和下行数据前，都会产生一个随机数，放入对应的随机数安全数据项。产生的随机数连续两次操作绝对不能相同，否则抛弃处理。得到随机数以后，通过对随机数的操作，选出主密匙Km。具体操作为，选取随机数第四字节与“0X07”进行“与”操作，再对其结果取模5的值，模5的结果（0~4之间）即为所要选择的主密匙索引号。主密匙组由联通公司提供，是一组（5个）十六字节十六进制数。具体程序如下：sms[1]=sms[2]=random(0xff);//产生四字节随机数sms[3]=sms[4]=random(0xff);keyindex=fmod((sms[26]&0x07),5);//选取Km（2）会话密匙Kc生成选择主密钥Km之后，采用标准的PBOC密钥分散算法对主密钥进行两级分散操作。分散因子包括“00”+用户卡ICCID后14位和随机数。流程如图3所示。OTA服务器端：产生下行数据前向序列号：A1用户卡端前向序列号：B1数据不合法完成数据交互：用户卡端前向序列号等于A1，OTA服务器前向序列号加1A1B1图3密钥分散算法求Kc示意图其中，PBOC算法流程描述如下：设主密钥为Km（16Bytes），分散因子为X（8Bytes，不足右补空格0X20），生成的分散密钥为Kc（16Bytes）。Km的左半部分（前8Bytes）为Kml，Km的右半部分（后8Bytes）为Kmr。Kcl=3DES（Km，X），Kcr=3DES（Km，NOTX），其中3DES为3DESECB类型。Kcl为Kc的左半部份，Kcr为Kc的右半部分。（3）MAC值计算计算MAC值采用标准的DES－CBC算法，初始密钥KEY为会话密钥Kc的左8个字节。上行与下行数据计算MAC值时，都应包含所有上行报文中的安全数据项。除此，上行还应包括，卡商代码及协议版本号、卡功能标识、ICCID等项；下行还应包括，命令类型、命令长度、命令参数等项。具体MAC值计算方法是，将所有原始数据按照每8个字节一组进行分组，若原始数据不是8的整数倍，则需要根据实际的数据长度在命令数据末尾填充1～7字节的“0x20”数据。计算MAC所需填充的数据不包含在上、下行报文数据中，由用户卡和OTA下载服务器在计算MAC码时根据上行、下行数据长度自行填充。以初始密匙KEY作为DES算法的密钥，初始数据为8字节的“0X00”，对第一分组数据与初始数据异或后的数据进行运算，DES算法的输出数据与第二分组数据异或后，继续以KEY为密钥进行DES运算，依次做下去直至最后一个分组处理完毕。MAC码取最后一次DES运算的8字节输出数据的最左边4字节数据。MAC算法流程如图4所示。图4MAC算法示意图根据随机数选择一支主密匙KmPBOCPBOC会话密匙Kc“00”+ICCID后14位随机数初始数据Block#1Block#2Block#3Block#NXORXORXORXORDESDESDESDESKEYKEYKEYKEYMAC四、结束语基于短消息的OTA数据传输方式，用户可以方便地利用短消息更新卡内的增值业务菜单，弥补了以前SIM卡固化业务的缺陷。因其简单易用，基于短消息的OTA数据传输方式得到了广泛的应用。目前，OTA业务主要用于SIM卡，随着3G业务的发展，网络条件的便利，增值业务必然会对处理速率、储存空间等提出更高要求，也必然会对当前的OTA数据传输安全模式提出更高求。因此，新的安全解决方案将成为今后OTA技术的研究方向。参考文献[1]中国联通OTA卡技术规范.第一部分:STK卡菜单OTA业务下载服务器技术规范.2006.10.[2]中国联通OTA卡技术规范.第二部分:支持OTA下载的STK卡技术规范.2006.10.[3]GSM03.48:Di