北斗短报文通信安全研究*
2019-12-04张舒黎石元兵
张舒黎,石元兵,王 雍
(成都卫士通信息产业股份有限公司,四川 成都 610041)
0 引 言
北斗卫星导航系统是我国自主发展、独立运行的全球卫星导航系统[1],为军、民用户提供了快速定位、实时导航、精密授时等服务功能[2]。北斗卫星导航系统最大的特色在于有源定位和短报文特色服务。它将短信和导航结合,区别于世界上其他几大导航定位系统。随着北斗卫星导航系统的逐步全球化,北斗短报文通信在民用领域的应用不断扩
充,在交通运输行业的“两客一危”车辆监控管理、远洋渔业通信、无人自动驾驶、农业精耕、电力监控、水文监测以及应急救援等各个领域发挥着重要作用。目前,在民口应用中,北斗短报文数据都是以明文方式进行传输,传输敏感数据时存在安全保护需求。本文从北斗短报文在数据传输中的应用中提炼抽象出共性的安全需求,结合商密算法进行研究,设计出普适的北斗短报文通信安全防护方案,确保北斗短报文安全通信。
1 北斗短报文通信安全分析
1.1 北斗短报文通信现状
北斗短报文通信系统由空间系统、地面系统和用户系统3部分组成[3],如图1所示。短报文发送和接收端通过出站、入站链路形成一个M型的通信机制。
图1 北斗短报文传输流程
目前,民用北斗短报文的传输过程为:发送端将生成的短报文发送给卫星,卫星收到短报文后根据接收端的地址进行广播;地面中心站收到卫星广播的短报文消息后,直接转发给另一个卫星;该卫星同样将短报文消息进行广播,接收端收到广播的短报文消息,即完成一次短报文通信。
北斗短报文通信涉及到两个协议,分别是4.0协议和2.1协议。4.0协议的全称是《北斗一号用户机数据接口要求》,版本4.0,2006年11月发布,简称4.0协议。4.0协议为二进制格式,目前民用北斗卡中,用户可输入的信息最长为78个字节。
2.1 协议的全称是《北斗卫星导航系统用户终端通用数据接口(预)》,版本2.1,2014年8月发布,简称2.1协议。2.1协议为文本格式,接口数据传输格式以语句的方式定义。以通信信息输出语句TXR为例,语句格式如下:
$--TXR,xxxxxxxx,x,hhmm,c--c*hh<CR><LF>
其中,“$”表示一条语句的开始;“hh”表示和校验字段,对“$”到“*”之间的字符执行XOR(异或)运算所得。通信的电文内容在“c--c”位置,内容必须以有效的ASCII字符表示。除去一些预留字符,能在电文内容出现的有效字符范围大小为89个。
1.2 北斗短报文通信安全需求
在北斗短报文通信传输过程中,短报文信息内容以明文的方式通过传输协议(对外公开)从发送端传递给地面中心,再由地面中心传递给接收端。在此过程中,除了对用户的身份验证,未对报文信息进行任何加密防护处理,可能导致报文信息被非法截获和恶意篡改,若敏感定位数据被泄露,将留下严重的安全隐患。下面归纳它的安全需求情况。
机密性需求。短报文直接传输明文信息,若敌手窃听到短报文,可以直接获得原始信息[4]。如果采用密码技术对数据进行加密,短报文传输的是原始信息的密文,此时即使敌手窃听到了短报文消息,在没有密钥的情况下其无法得到真实的原始信息,进而可以避免信息泄露带来的损失。
完整性需求。短报文直接传输信息没有进行完整性保护,一方面传输发生错误时,短报文的接收者可能会解析出错误的误导信息;另一方面,敌手可对传输的信息进行篡改或进行消息重放攻击,进而导致短报文的接收者解析出误导的信息。如果采用密码技术对数据进行完整性保护,则短报文的接收者可对不满足完整性的消息直接丢弃,进而避免上述情况的发生。
2 北斗短报文通信安全应用
2.1 总体介绍
在北斗短报文通信中,用户通过北斗终端输入信息,经由北斗卫星及地面中心站发送至另一终端用户,该过程可简要以图2表示。
图2 北斗短报文通信流程
其中,用户A输入的数据在终端A被编码为北斗报文的特定格式,然后通过北斗卫星、地面中心站等发送至终端B,在终端B中解码并呈现给用户B。为保护报文在传送过程中的安全,在终端内部增加密码模块,使得报文以密文形态在链路上被安全传输。
本文设计两种安全通信方案:一种是地面中心参与的加解密方案,另一种是地面中心不参与的加解密方案。考虑到北斗终端的计算能力有限以及其可传输报文长度的限制,本文将采用商用对称密码算法SM4[5]实现对短报文内容的加密保护。
2.2 地面中心参与加解密的短报文安全通信方案
为保护报文在传送过程中的安全,在终端内部增加密码模块,使得报文在发送端先加密后再发送,经地面中心站解密并使用接收端的密钥加密后再发送至接收端。此方案的北斗短报文加密通信如图3所示。
图3 北斗短报文加密通信
图3 中,终端设备内置密码软模块,支持本方案所设计的加解密机制。地面中心与密管中心配备有各自的密码机。密管中心的密码机负责密钥的生成、数据加解密。地面中心的密码机只负责数据加解密。在密管中心和地面中心之间存在安全通道,能够对数据进行安全传输。此外,密管中心和地面中心有各自的存储设备,能够存储保护后的数据。
密钥分发。密管中心负责向北斗卡和地面中心分发密钥。密管中心生成终端密钥并内置在北斗卡中,将北斗卡分发给各个用户。同时,密管中心将已分发的北斗卡终端密钥、为地面中心站产生的地面中心主密钥、密钥加密密钥都通过安全通道分发给地面中心站。密管中心的密钥分发如图4所示。
地面中心将地面中心主密钥作为SM4算法的密钥,对密钥加密密钥进行加密和存储;将密钥加密密钥作为SM4算法的密钥,对所有终端密钥进行加密和存储。
加解密过程,如图5所示。
图4 密管中心的密钥分发
图5 短报文加解密示意过程
由图5所示,发送方终端A在对短报文加密时,使用终端密钥作为SM4等对称算法的加密密钥对明文进行加密,发送生成的密文。地面中心站接收到终端A发送的密文后,使用与终端A共享的终端密钥对短报文中的密文进行解密得到明文。然后,地面中心站根据短报文接收方B的终端密钥,按照与终端A相同的SM4算法对明文进行加密,后将密文打包发送。地面中心站在查询终端A和B的终端密钥的时候,需先使用地面中心主密钥对密钥加密密钥进行解密,再使用密钥加密密钥解密终端A和B的终端密钥。接收方终端B收到密文后,使用自己的终端密钥对密文进行解密,获得原始的明文消息。具体流程如图6所示。
设北斗终端或地面中心站输入信息为M,密钥为Keyi,当前时间为T,加密算法运算过程如下:
1.inputM,Keyi,T
2.MAC=SM3(M,Keyi,T)
3.MAC´=Truncl(MAC,LMACi)
4.M´=M||MAC´||T
5.C=SM4.Enc(M’Keyi)
6.outputC
解密算法如下:设北斗终端或地面中心站输入的报文信息为C,密钥为Keyi,解密算法运算过程如下:
1.inputC,Keyi
2.M´=SM4.Dec(C,Keyi)
3.T=Truncr(M´,LT)
4.M=Truncl(M´,Len(M´)-LMAC-LT)
5.MAC=SM3(M,Keyi,T)
6.ifM=Truncl(MAC,LMAC)==
Truncl(Truncl(M´,LMAC+LT),LMAC)
7.OutputM
8.else
9.output ERROR!
图6 北斗短报文通信加解密流程
2.3 地面中心不参与加解密的短报文安全通信方案
为保护短报文在传送过程中的安全,设计端到端的加密方案。在终端内部增加密码模块,使得报文在发送端先加密后再发送,经地面中心站转发后再传送至接收端,由接收端进行解密。此处,地面中心仅负责短报文消息的中继转发。需要注意的是,如果需要实现地面中心对短报文内容进行监控,也可对其添加密码模块,并且由密管中心分享终端密钥给地面中心,使其能够对短报文消息进行解密查看。此方案的北斗短报文加密通信如图7所示。
图7 地面中心不参与的北斗短报文通信
图7 中,终端设备内置加密卡,支持本方案所设计的加解密机制。密管中心配备有密码机,密管中心的密码机负责密钥的生成和分发,将终端密钥写入北斗卡并分发给注册用户。其余步骤与地面中心参与加解密的短报文安全通信方案类同。
2.4 两种短报文安全通信方案的对比
本文针对短报文的通信防护,根据地面中心是否参与短报文的加解密过程(是否需要对现有的地面中心进行改造升级)分别设计了两种安全通信方案。对这两种方案进行多方面对比(如表1所示),以帮助决策者因地制宜地选择方案。
表1 两种短报文安全通信方案对比
3 实验分析
受场地和条件限制,本文只对地面中心不参与加解密的安全方案进行试验验证。实验验证实验环境搭建如图8所示。
图8 短报文加密通信实验验证实验环境
试验结果表明,北斗短报文传输过程中的延时通常控制在1~2 s,测试数据分析图如图9所示。
图9 测试数据分析
测试结论分析:使用SM4、ZUC加密算法后延时时间极小,约在微秒到毫秒级,远小于60 s的等待频度;数据加解密后长度有微小的扩张(传输MAC值和时间戳T)。
4 结 语
本文对北斗短报文通信应用进行研究,分析其安全现状,总结安全防护需求,并基于国家密码局发布的商密算法对北斗短报文通信进行加密安全防护设计,最后对方案进行试验验证。本文设计的北斗短报文通信安全防护方案通过了在交通部的北斗卫星导航系统交通运输行业数据传输加密与应用安全防护的课题研究专家评审。