基于手機應用程序的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.