基于手机应用程序的Telematics解决方案安全策略分析

汪振兴

（上海大众汽车有限公司，上海 201805）

近年来，随着移动通信技术的发展以及家用轿车的普及，Telematics呈现出很强的发展势头。同时，无线通信带宽的提升和智能手机的普及，也使移动互联网应用得到了快速发展，而智能手机应用程序作为用户对移动应用服务的重要体验渠道，已经越来越为广大移动终端用户所接受［1-2］。

考虑中国市场的特点和消费观念，利用蓝牙控制器和手机应用程序进行数据交互，可提供一种低成本的Telematics解决方案。保证数据传输安全，是该方案的一个核心问题。

整车生产商在IT系统建设规划中，也顺应当前移动应用的发展趋势，充分认识到，智能手机应用将会成为今后整车生产商企业信息化建设和车主客户信息化服务的重要工具。因此，需要对建设自主开发的、高品质的智能手机App应用做好充分准备。

本文将详细讨论整车厂对智能手机App应用程序的安全性保障方案，可为后续自主建设以及指导供应商进行车辆相关App开发提供有益的参考。

1 方案介绍

本文介绍的Telematics方案是一种低成本的解决方案，整个系统包括车载的T-Box控制器、手机应用程序和提供服务的后台服务器。

T-Box控制器主要部件包括蓝牙模块、CAN收发器及电源管理模块等。车辆CAN总线上的信息通过蓝牙SPP协议发送至手机，T-Box与手机的蓝牙数据传输具有完善的加密机制，保证了传输数据的安全。

本文所指的手机App程序是指需要和后台以及T-Box有信息交互的App程序，具体功能基于整车的CAN信息进行开发，可灵活地进行扩充升级。对于T-Box工作的模式、运行参数，手机APP可以配置，并且将配置下发到T-Box生效，例如T-Box对CAN信息的采集频率等。T-Box可通过后台远程进行激活、启用或停用。启用的时候，能够上传数据；停用的时候，不能上传数据。

本方案的特点是将智能手机作为信息中枢，就是把车载终端、呼叫中心、个人门户网站、车厂用户数据库、SP／CP服务器串联在一起，为用户提供前所未有的服务体验。其优势不言而喻，此种模式最大程度地发挥了智能手机的作用，紧密捆绑最终用户，可以为车主提供最有吸引力的服务。其系统架构灵活，极具拓展性。采用这种方案，车厂需要做的工作是，前瞻性地设计各个部分与智能手机间的功能接口和通信方式。一个重要影响因素是，今后蓝牙智能手机的渗透率和功能将对整个服务体系产生影响。

在这种模式下，智能手机的作用明显得到了提升，它是作为信息中枢的角色存在的。如此设计，基于两点考虑。一是智能手机的CPU很少有低于1GHz的，其运算能力强劲甚至超过车载终端。将众多的应用程序运行在这个平台上，充分挖掘了智能手机的潜力。另一方面，还是成本的考虑，提升车载终端的硬件运算能力及安全设置，投入很大。

这里要提到一个 “三屏一云”的概念，即车载终端屏、用户手机屏及PC屏三屏，以及后台服务器这个云。PC端与手机是控制中心，大部分的设定，通过计算机与手机完成，尽量解放车主，使其不用在车内进行更多类似于计算机与手机的复杂操作，而车载终端屏是结果中心，它会将用户在PC与手机上所做的所有设定，经过智能运算之后，很好地表达出来。通过无线网络连接的数据中心，里面放置了很多地图、资讯、生活以及一些个人信息，这就是所谓的云计算概念。不仅仅依靠车内单机设备及手机的运算能力，而且同时有着上百台服务器在帮助汽车变得更加智能，使得行车效率与车内娱乐更如人所愿。这一设计的理念是，用户所购买的不是一个孤立的车辆，而是一整套体系严格的智能系统。用户给车辆的信息越多，它反馈给用户的智能化表现则越多，而且手机应用程序可以不断地升级，让用户领先体验最适合自己的汽车智能生活。

2 安全策略

1）认证 需要对车载设备T-Box及手机，终端用户及手机APP供应商进行认证，以确保安全性。

使用T-Box的ID进行配对后，可将T-Box设为认证的设备。对于匹配的蓝牙智能手机，手机的IMEI／UDID被用来进行认证。车辆的VIN码在这个过程中也被使用。账户名和密码可作为登录凭证，在第一次登录时，账号和设备需要激活。同时，考虑到用户的手机可能丢失或被盗，账号和设备也可重新激活或注销。整车厂提供的是一个开放的平台，不仅是一个供应商可以为其开发应用程序，只要是整车厂授权，并获得一个独特的应用程序key（供应商ID／密码），其他供应商也可以。只有经过整车厂授权的厂商能够开发应用程序，用以连接TBox并访问后台服务。

2）加密 需要对蓝牙通道 （T-Box至手机）、空中通道 （手机至后台）以及本地敏感数据进行加密。

T-Box和手机之间的通信使用非对称的RSA及对称的AES进行加密，动态的AES密钥使用RSA进行加密。考虑到来源及效率，本文使用ECC方案。手机和后台之间的通信使用HTTPS进行加密。对于本地敏感数据，例如登录凭证、后台服务的IP／URL以及历史服务数据，则使用AES强加密方案。系统架构和安全策略如图1所示。

3 加密机制

非对称加密算法体制中，用作机密的密钥不同于用于解密的密钥，而其解密的密钥不能根据加密密钥计算出来 （至少在合理假定的长时间内）。在公钥密码系统里，加密密钥叫做公钥，解密密钥叫做私钥。公钥加密技术是针对对称密码体制的缺陷被提出来的。在公钥加密系统中，加密和解密是相对独立的，加密和解密会使用2把不同的密钥，加密密钥 （公开密钥）向公众公开，谁都可以使用，解密密钥 （秘密密钥）只有解密人自己知道，非法使用者根据公开的加密密钥无法推算出解密密钥，故其可称为公钥密码体制。如果一个人选择并公布了他的公钥，另外任何人都可以用这一公钥来加密传送给那个人的消息。私钥是秘密保存的，只有私钥的所有者才能利用私钥对密文进行解密。非对称加密算法中最著名的代表是RSA算法。

对称密码算法有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，反过来也成立。在大多数对称算法中，加密解密密钥是相同的。这些算法也叫秘密密钥算法或单密钥算法，它要求发送者和接收者在安全通信之前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人都能对消息进行加密解密。只要通信需要保密，密钥就必须保密。对称密码术的优点在于效率高，算法简单，系统开销小，适合加密大量数据。典型的对称密码算法有AES算法［3］。

数字证书则是由证书认证机构 （CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名 （相当于加盖发证书机构的公章）后形成的一个数字文件。CA完成签发证书后，会将证书发布在CA的证书库 （目录服务器）中，任何人都可以查询和下载，因此数字证书和公钥一样是公开的。实际上，数字证书就是经过CA认证过的公钥。

3.1 加密原则

1）一个公钥对应一个私钥。

2）密钥对中，让大家都知道的是公钥；不告诉大家，只有自己知道的，是私钥。

3）如果用其中一个密钥加密数据，则只有对应的那个密钥才可以解密。

4）如果用其中一个密钥可以进行解密数据，则该数据必然是对应的那个密钥进行的加密。

5）非对称密钥密码的主要应用就是公钥加密和公钥认证，而公钥加密的过程和公钥认证的过程是不一样的。

3.2 加密解密过程

基于公开密钥的加密过程：比如有2个用户Tom和John，Tom想把一段明文通过双钥加密的技术发送给John，John有一对公钥和私钥，那么加密解密的过程如下。

1）John将他的公开密钥传送给Tom。

2）Tom用John的公开密钥加密他的消息，然后传送给John。

3）John用他的私人密钥解密Tom的消息。

3.3 身份认证

基于公开密钥的认证过程：身份认证和加密就不同了，主要用于鉴别用户的真伪。这里我们只要能够鉴别一个用户的私钥是正确的，就可以鉴别这个用户的真伪。还是Tom和John这2个用户，Tom想让John知道自己是真实的Tom，而不是假冒的，因此Tom只要使用公钥密码将文件签名发送给John，John使用Tom的公钥对文件进行解密，如果可以解密成功，则证明Tom的私钥是正确的，因而就完成了对Tom的身份鉴别。整个身份认证的过程如下。

1）Tom用他的私人密钥对文件加密，从而对文件签名。

2）Tom将签名的文件传送给John。

3）John用Tom的公钥解密文件，从而验证签名。

3.4 公钥、私钥、证书的生成

1）一个HTTPS服务器首先创建他自己的密钥对 （key pair），包含公钥和私钥。

2）通过网络把他的公钥送到CA中心，公钥中包含了个人鉴别信息 （他的名字、地址、所用设备的序列号等）。

3）CA中心创建并签署一个包含公钥及个人信息的证书，从而保证密钥的确实性。

4）使用该证书的人可以通过检验CA中心的签名 （检验CA签名需要CA的公钥）来验证证书的确实性。

3.5 公钥、私钥、证书的使用

在HTTPS协议的握手阶段是公钥、私钥、证书的典型使用场景。HTTPS握手的典型时序图如图2所示。

图2中实线部分是必须的，虚线部分是可选的。该流程完成了2个任务：服务器身份的验证、加密传输对称加密密钥。虚线部分是服务器端要求验证客户身份。

1）Client Hello和Server Hello表示双方要建立一个加密会话。

2）服务器把数字证书传输给客户端，证书中包含服务器公钥，客户端用公钥解析证书中的数字签名，可以验证服务器的身份。

3）Server Hello Done表示hello流程结束。

4）客户端生成一个对称加密密钥，用于实际数据的加密传输，并用服务器的公钥加密，把对生成的密钥传递给服务器。同时携带一个用刚刚生成的加密密钥加密的 “client finished”。

5）服务器收到对称加密密钥，并尝试用该密钥解密加密字段，如能得到明文 “client finished”，认为该密钥有效，可以用于之后的数据加密传输。同时用该密钥加密 “server finished”，传递给客户端。

6）客户端用对称机密密钥解密，如能得到明文 “server finished”，客户端认为该服务器已经正确地接收到对称密钥。

7）加密数据传输开始。

4 手机App安全方案

智能手机App从状态上可以分解为以下2种状态，在这2种状态下，都要采取App安全性保障策略。

状态1：运行时状态——App程序已经启动的状态。

状态2：非运行时状态——App程序已下载或者已安装，但是未启动的状态。

4.1 状态1——运行时状态安全性保障方案

App和后台交互时，即空中通道 （手机至后台），在网络传输安全性方面，根据业界标准，App使用Https／SSL协议技术实现安全性保障。

超文本传输安全协议 （Hypertext Transfer Protocol Secure，缩写：Https）是超文本传输协议和SSL／TLS的组合，用以提供加密通信及对网络服务器身份的鉴定。Https连接被广泛用于互联网及移动互联网上的交易支付和企业信息系统中敏感信息的传输。Https能保障数据传输安全性，使用SSL协议保障安全。

手机应用程序和车载模块T-Box之间的数据传输通过SPP蓝牙协议进行，但会话过程是加密的。利用后台服务器，使用非对称的RSA加密算法加密对称加密算法AES的密钥，而车载信息模块和手机应用程序之间的数据传输采用AES的密钥加密。具体过程如下。

1）蓝牙SPP连接成功，手机给车载信息模块一个消息，包括程序ID、进程ID、手机蓝牙MACP及初始化信息，同时也将这些信息发给后台服务器。

2）车载信息模块根据本身存储的手机蓝牙MACP及程序ID，对比该手机发来的信息，验证手机和程序的合法性，并给出相应的握手信息给手机。同时，利用车载信息模块ID及时间动态生成AES密钥 （KA）。

3）后台服务器对比用户账户，检查手机号码及程序ID，并给出相应的握手信息给手机，若不匹配则断开连接。

4）对于本地的数据，如惯导信息，仅使用蓝牙进行传输，无需额外加密处理。

5）车载信息模块使用RSA的公钥Kpub加密KA、车载信息模块ID、蓝牙MACP、蓝牙MACT，并将该字串发送到后台服务器。

6）后台服务器使用RSA的私钥解密该字串，得到AES密钥KA，并使用KA加密程序&进程ID、Ack／Nack。

7）车载信息模块检查程序&进程ID，如果匹配，保留这些ID，否则断开连接，同时使用AES密钥KA加密Ack或Nack。

8）至此，加密的会话通道建立，此后所有传输的数据用AES加密，每次SPP连接都运行此过程。

现在绝大部分App只在初次使用时，要求用户必须输入用户名和密码，以后都是启动程序就可以直接登录App，本方案也采用这种方式，而这种方式背后，先进的做法就是依靠AuthenToken机制在保证App与后台交换的安全性。

AuthenToken数据交互机制，是指App与后台之间均加上了自主设计的访问令牌方式保障数据传输安全。所谓访问令牌 （AuthenToken）是一种类似于服务器SESSION的方式，用于存储用户的状态信息。用户在登录系统时会收到系统发了这样一个令牌 （这个令牌不是简单的随机产生，是系统根据用户信息进行部分技术处理而产生的一串字符码，永远不会和其他用户或者该用户上一次登录相重复），只有当该令牌在有效期内，用户才能通过以加上该令牌的方式访问业务。任何一种登出都会使令牌失效。

如客户首次使用App需要输入密码，我们要求用户的密码是用AES加密后再传输，以更好地保障密码安全性，当然这同样要求后台数据库中的用户密码也是AES加密保存。

4.2 状态2——非运行时状态安全性保障方案

对于手机App本身，为了保证安全，需要防御对其进行的反编译。因此在App代码编译时，需对其进行混淆。IOS应用程序不需要做混淆，其已经编译成机器码了。

5 结束语

随着网络技术的发展，APP STORE的兴起，以及中国汽车市场的繁荣，基于车辆的App应用一定会有长足的发展。本文所介绍的基于手机应用程序的Telematics方案，是适应当前市场环境的一个快速有效方案，针对其所提供的一整套的安全加密策略，充分保证了整个系统的安全，经过小批量装车试运行，结果证明该设计方案有效合理，效果令人满意。对于其他类型的App设计同样具有借鉴意义。

［1］ 余嵘. 车载Telematics系统研究［J］. 汽车电器， 2011 （7）：1-4.

［2］殷建红.国内车载娱乐系统发展现状及趋势［J］.汽车与配件， 2009 （11）： 40-42.

［3］俞经善.基于ECC和AES相结合的加密系统的实现［J］.信息技术，2006 （2）：44-46.