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