《汽車整車信息安全技術要求》（征求意見稿）編制說明

《汽車整車信息安全技術要求》

編制說明

一、工作簡況

（一）任務來源

根據國家標準化管理委員會《關于下達<包裝機械安全要求>等31項強制性國家標準制

修訂計劃及相關標準外文版計劃的通知》（國標委發(fā)〔2021〕27號）中項目編號

20214422-Q-339的強制性國家標準制定項目，制定強制性國家標準《汽車整車信息安全技

術要求》。

（二）主要工作過程

受工業(yè)和信息化部委托，全國汽標委智能網聯汽車分標委根據單位申請情況成立標準起

草項目組，確定中國汽車技術研究中心有限公司、國汽（北京）智能網聯汽車研究院有限公

司和電子科技大學為標準起草項目組牽頭單位，并在此基礎上明確了任務和分工，積極開展

標準的預研、起草及征求意見等工作。

自標準制定工作啟動以來，牽頭單位多次組織項目組成員單位召開項目組會議，分析了

聯合國等國際標準法規(guī)組織的汽車標準法規(guī)現狀，討論確定了適應中國汽車產業(yè)發(fā)展現狀的

汽車整車信息安全的技術要求并編寫了標準草案，最終完成了標準的征求意見稿。

2019年11月啟動標準編制工作，成立項目組，召開第1次會議。

2019年12月就標準邊界及制定思路等內容征集各單位意見。

2020年3月項目組第2次會議（線上），圍繞制定思路及框架展開討論。

2020年4月～5月確定框架、征求參編意向并分工編寫。

2020年6月～9月形成標準草案并提交立項申請。

2020年10月項目組第3次會議，持續(xù)完善標準草案。

2021年3月～4月根據行業(yè)管理需求和主管部門要求，將原推薦性國家標準項目調整

為強制性國家標準項目。

2021年4月項目組第4次會議，完成本標準與UNWP29R155法規(guī)的對比分析。

2021年5月～7月組織多次封閉寫稿和專題研討會議，持續(xù)完善標準草案。

2021年7月項目組第5次會議，充分參照R155法規(guī)及解釋文件形成標準草案。

2021年8月～9月組織多次封閉寫稿和專題研討會議，持續(xù)完善標準草案。

2021年10月項目組第6次會議，對草案進行詳細討論，確定技術要求框架，形

成試驗方法。

2022年1月～6月組織行業(yè)開展標準驗證試驗工作，包括企業(yè)信息安全管理審核、車

輛技術要求及試驗方法驗證。

2022年7月～8月在汽車信息安全標準工作組進行征集意見，收集反饋意見并召開意

1

見協調會，形成意見處理結論。

2022年9月根據意見反饋修改形成公開征求意見稿和編制說明。

1.項目組第一次會議

汽車整車信息安全技術要求標準項目組第一次會議于2019年11月5日在杭州召開，正

式啟動標準制定工作。會議就標準的制定背景、范圍、目標、框架、進度計劃、研制思路等

進行了討論，對一些共性問題進行了探討，會議明確標準撰寫的整體思路按照整車開發(fā)流程

V字型的架構來設計，需要和《汽車信息安全通用技術要求》的安全原則及需求相結合，綜

合考慮標準的對象，并在會后對標準框架開展進一步總結與梳理。

2.項目組第二次會議

汽車整車信息安全技術要求標準項目組第二次工作會議于2020年3月4日在線上召開，

會議進一步圍繞標準背景及項目計劃、編寫思路、框架等展開討論。會議明確了標準定位是

從整車視角出發(fā)綜合考量，不包括對零部件單獨的安全要求，技術要求和測試對象以整車為

主；標準不區(qū)分不同的駕駛自動化級別，而是適用于道路車輛的通用基本要求。會議就標準

下一步編制工作的分工進行了安排，由威脅分析與風險評估、外部訪問點安全、內部網絡通

信安全、基于業(yè)務的安全、基于功能的安全、數據安全要求等7個部分分工編寫，形成V1.0

版草案。

3.項目組第三次會議

汽車整車信息安全技術要求標準項目組第三次工作會議于2020年10月21日在北京召

開。會議討論了標準的總體框架、編制思路，并由整車威脅分析與風險評估、外部訪問點安

全、內部網絡通信安全、基于業(yè)務的安全、基于功能的安全、數據安全要求等7個部分對各

章的編寫思路和遇到的問題進行了交流與討論，基于討論進一步協調統一了標準框架、編寫

方式及要求力度等，并在會后面向項目組內廣泛征集各章節(jié)的編寫意見。

4.項目組第四次會議

汽車整車信息安全技術要求標準項目組第四次工作會議于2021年4月26日在天津召開。

會議對本標準轉為強標的背景進行了介紹，增進項目組全體成員對現有標準內容的理解；明

確了整體的時間進度計劃、各節(jié)點任務，明確各章節(jié)任務分工、工作思路和計劃。會議明確

本標準作為國家強制標準，不一定代表技術先進性，而側重考量技術的廣泛性和通用性，每

條技術要求的提出都應力求必要、精簡凝練，并且要著重考慮與UNR155法規(guī)的國際協調；

圍繞法規(guī)原文對標準框架設置和章節(jié)內容進行了對應的優(yōu)化與調整。

5.作為強制性國家標準重新立項

2021年7月，為貫徹落實《網絡安全法》《數據安全法》等，應對智能網聯汽車信息

安全風險與挑戰(zhàn)，主管部門出于產業(yè)安全發(fā)展及行業(yè)管理需要，將該推薦性國家標準項目調

整為強制性國家標準項目，為保障產業(yè)健康可持續(xù)發(fā)展劃定信息安全基線要求。

6.項目組第五次會議

汽車整車信息安全技術要求標準項目組第五次工作會議于2021年7月26-29日在廈門

召開。本次會議擴大了項目組成員的參與范圍，主要針對車輛技術要求部分進行封閉寫稿及

2

討論，并就各章節(jié)內容的編寫情況逐一進行介紹和全體討論，基本確定了標準的框架及主體

內容，形成V2.0版草案，并參考GB40050等信息安全行業(yè)重點標準的行文表述方式，統

一梳理標準內容及行文。

7.項目組第六次會議

汽車整車信息安全技術要求標準項目組第六次工作會議于2021年10月12-13日在成都

召開。本次會議在項目組內對標準的技術要求條款進行逐條地討論、完善及確認，并初步討

論了管理章節(jié)的內容及試驗開展的思路，為試驗方法編寫提供參考。會議形成的標準草案

V3.0版，主要包括管理要求、車型技術要求、試驗方法3大部分內容，同時，明確了本標

準不提出唯一限定的技術要求和試驗方法，希望企業(yè)在充分的風險評估的基礎上開展。后續(xù)

將重點解決各章節(jié)存在內容交叉、重復的問題，進一步優(yōu)化完善技術要求，增加相應的試驗

方法，部署標準驗證試驗工作。

8.標準驗證試驗

2022年1月-6月，汽標委智能網聯汽車分標委秘書處根據標準編制工作計劃開展本標

準驗證試驗，驗證試驗項目包括：汽車信息安全管理體系審核，在申請企業(yè)所在地及線上同

步開展；車輛技術要求及試驗方法驗證，在相關試驗機構開展。秘書處面向汽車信息安全標

準工作組廣泛征集參與企業(yè)及試驗車輛，由于本標準試驗驗證條款數量較多、準備工作復雜、

體系驗證需大量相關方配合、整體試驗周期較長、試驗驗證資源有限，按照整車產品安全開

發(fā)程度及企業(yè)信息安全管理體系建設完備程度，從征集到的24家汽車生產企業(yè)中最終選取

了12家企業(yè)隨機分配至6家檢測機構共同開展驗證試驗。受疫情影響，以線上線下相結合

的方式先后完成所有車輛的標準驗證試驗及信息安全管理體系審核工作，總結試驗過程中的

經驗和問題，進一步完善標準草案。

9.試驗工作專題啟動會

汽車整車信息安全技術要求的試驗工作專題啟動會于2022年3月1日以線上會議召開。

本次會議由秘書處及6家試驗機構共同參與，本次會議部署了開展驗證試驗的工作要求，并

重點研討確定標準驗證試驗實施方案及具體工作計劃。明確了以驗證標準草案中各條要求的

合理性和可實施性為出發(fā)點，核查標準要求是否為基線要求。

10.工作組意見協調會

2022年7月31日，形成工作組征求意見稿，并面向汽標委智能網聯汽車分標委汽車信

息安全標準工作組100余家單位征求意見。本次反饋意見共計收到78家單位的意見反饋，

標準項目組于8月30日至9月6日召開意見處理協調會議，根據反饋意見進行了逐條討論

處理，并根據相關意見對標準公開征求意見稿和編制說明進行了修改。

二、編制原則、強制性國家標準主要技術要求的依據及理由

本文件編寫符合GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和

起草規(guī)則》的規(guī)定起草。起草過程，充分考慮國內外現有相關標準的統一和協調；標準的要

求充分考慮了國內當前的行業(yè)技術水平，對草案內容進行多次征求意見和充分討論。

3

（一）適用范圍

本文件規(guī)定了汽車信息安全管理體系要求、車輛信息安全一般要求、車輛信息安全技術

要求、審核評估及測試驗證方法。

本文件適用于M類、N類及至少裝有1個電子控制單元的O類車輛，其他類型車輛可

參考執(zhí)行。

（二）主要技術內容

本標準主要技術內容包括6個部分，以下選擇標準技術要求的部分重點內容進行說明：

第5章信息安全管理體系要求

基于國內行業(yè)技術發(fā)展現狀，參考R155法規(guī)第7.2章節(jié)的內容，針對如下方面提出要

求：

（1）車輛制造商應建立車輛全生命周期的信息安全管理體系。

說明：本標準條款所要求的信息安全管理體系以車輛產品為核心，應覆蓋車輛的全生命

周期。若流程、規(guī)定等僅與企業(yè)經營管理、組織自身運營相關，并不涉及車輛產品信息安全

相關話題，則不在本標準所要求的體系范圍內。

（2）應建立識別、評估、分類、處置車輛信息安全風險及核實已識別風險得到適當處

置的流程，并確保車輛風險評估保持最新狀態(tài)。

說明：本條款要求汽車生產企業(yè)針對車輛的信息安全風險進行識別、評估、分類、處置

等相關管控活動，并建立相應的流程。此處的流程應能夠應對車輛全生命周期的風險管控，

企業(yè)可自行定義實施路線。

（3）應包含漏洞管理機制，明確漏洞收集、分析、報告、處置、發(fā)布等活動環(huán)節(jié)。

說明：本條款明確要求企業(yè)建立漏洞管理機制，并且需涵蓋收集、分析、報告、處置、

發(fā)布等關鍵環(huán)節(jié)。

第6章車輛信息安全一般要求

基于國內行業(yè)技術發(fā)展現狀，參考R155法規(guī)中第7.3章節(jié)的內容，及附錄5中的部分

相關內容（表A14.3.4、4.3.7有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B3、

B5中有關的緩解措施），針對如下方面提出要求：

（1）車輛產品開發(fā)流程應遵循汽車信息安全管理體系要求。

說明：車輛產品應按照汽車信息安全管理體系中定義的相關流程、制度開展開發(fā)工作。

（2）識別和管理車輛與供應商相關的風險。

說明：此處“供應商”關注與車輛產品風險相關的供應商，包括合同供應商、服務提供

商等。

（3）應針對車輛實施相應措施，以識別和防御針對該車輛的網絡攻擊、網絡威脅和漏

洞，并為車輛生產企業(yè)在識別與車輛相關的網絡攻擊、網絡威脅和漏洞方面提供監(jiān)測能力，

以及為分析網絡攻擊、網絡威脅和漏洞提供數據取證能力。

4

說明：車輛產品端應實施相應的措施，與企業(yè)在汽車信息安全管理體系中建立的網絡攻

擊、網絡威脅和漏洞的監(jiān)測和響應流程進行協同，從而保障企業(yè)可以針對車輛產品進行網絡

攻擊、網絡威脅和漏洞方面的監(jiān)測，并且支持數據取證。

第7章車輛外部連接安全要求

基于國內行業(yè)技術發(fā)展現狀，參考R155法規(guī)附錄5中的相關內容（表A14.3.1、4.3.5

有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B4中有關的緩解措施），針對如下

方面提出要求：

（1）對具備遠程控制功能系統的安全要求，包括對遠程控制指令信息的真實性和完整

性驗證、驗證失敗的處理功能、對遠程控制指令設置訪問控制、安全日志記錄、對車端遠程

操控功能系統的程序和配置數據的完整性驗證要求等。

（2）對第三方應用安裝運行的要求，第三方應用是指汽車制造商及其供應商之外的其

他法人實體提供的面向用戶提供服務的應用程序，包括通過應用商店或瀏覽器或USB等用戶

安裝的應用軟件，汽車制造商應對其授權和認可的第三方應用的真實性和完整性進行驗證，

防止該應用被篡改；汽車制造商應對其未授權的第三方應用的安裝運行采取防護措施，如在

安裝時進行提示、限制其訪問權限，避免非授權的第三方應用對車輛系統等的資源配置、關

鍵參數、重要數據等進行訪問。

（3）對外部接口的安全要求，包括對USB接口、診斷接口和其他接口的設備進行訪問

控制，禁止非授權訪問。應對USB端口接入設備中的文件進行訪問控制，只允許指定格式的

文件讀寫或指定簽名的應用軟件安裝或執(zhí)行，應具備USB端口接入設備中病毒程序或攜帶病

毒的媒體文件/應用軟件的鑒別并禁止安裝的能力，對通過診斷接口發(fā)送的對車輛關鍵參數

寫操作請求時，進行身份鑒別、訪問控制等安全策略。

（4）對車輛外部連接系統漏洞管理的要求，包括但不限于遠程控制系統、授權的第三

方應用等，應不存在由權威漏洞平臺6個月前公布且未經處置的高危及以上的安全漏洞，處

置措施包括消除漏洞、制定減緩措施等。

（5）對網絡端口的安全要求，應關閉不必要網絡端口，如TCP連接或UDP消息的邏輯

信道端點等。

第8章車輛通信安全要求

基于國內行業(yè)技術發(fā)展現狀，參考R155法規(guī)附錄5中的相關內容（表A14.3.2有關脆

弱性/威脅的描述、漏洞及攻擊方法示例，以及表B1、B5中有關的緩解措施），針對如下

方面提出要求：

（1）車輛與車輛生產企業(yè)云平臺通信時，應對其通信對象的身份真實性進行驗證。

說明：本文件并未強制要求雙向認證、也未強制要求必須使用證書保護機制。

（2）車輛與車輛、路側單元、移動終端等進行直連通信時，應進行證書有效性和合法

性的驗證。

5

說明：本條款主要是針對V2X場景提出的要求。

（3）車輛應采用完整性保護機制保護外部通信通道。

說明：本條款主要針對能夠在通信協議層面實現完整性保護機制的外部通信通道。某些

外部通信通道例如RFID、NFC等，不適用此條款；無線傳感器與車載設備之間的通信、語

音交互也不適用于本條款；對于企業(yè)采用的完整性保護技術類型和強度，本文件不做具體要

求。

（4）應對車輛發(fā)送的敏感個人信息實施保密性保護。

說明：本文件旨在對車輛的信息安全風險提出安全要求，具體“敏感個人信息”的定義

以汽車數據安全相關管理要求和標準規(guī)定為準。

（5）車輛與外部直接通信的零部件應具備安全機制防止非授權的系統特權訪問。

說明：本條款僅包含與外部直接通信的零部件，利用T-BOX，車載信息交互系統間接

與外部通信的零部件不適用于本條款的要求；射頻、NFC等短距離無線通信的傳感器也不

適用于本條款要求；身份識別機制包括基于密碼的認證機制、DTC記錄、日志記錄、異常

提醒等，對外部通信零部件進行身份識別的技術可通過云端來實現。

（6）車輛應具有識別惡意的V2X數據、惡意的診斷數據、惡意的專有數據等的能力，

并采取防護措施。

說明：惡意的診斷數據包括非法診斷請求、非法診斷應答、暴力請求認證、非法開啟

DTC主動上傳、惡意連續(xù)復位等；本條款使用“數據”而不是消息或指令等表述方式，是

為了全文統一考慮，其本身是廣義的概念，可指代原文的“惡意消息”具；體惡意數據的定

義由廠家決定并提供清單作為測試的輸入。

（7）車輛應對關鍵的通信信息安全事件進行日志記錄。

說明：本條款對車輛通信信息安全事件日志記錄提出了要求，安全日志防護應滿足第

10章數據代碼章節(jié)的要求。

第9章軟件升級安全要求

基于國內行業(yè)技術發(fā)展現狀，參考R155法規(guī)附錄5以及R156法規(guī)中的相關內容（表A1

4.3.3有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B2中有關的緩解措施），針對

如下方面提出要求：

（1）車載軟件升級系統應具備安全啟動的功能，應保護車載軟件升級系統的可信根、

引導加載程序、系統固件不被篡改，或被篡改后無法正常啟動。

說明：車載軟件升級系統在行業(yè)和某些企業(yè)也被稱為車端OTAMaster，包括系統軟件

和硬件；該條款的正常啟動是指車載軟件升級系統默認加載程序的啟動；本文件中將除默認

加載程序的啟動之外，均視為非正常啟動。

（2）車載軟件升級系統應不存在由權威漏洞平臺6個月前公布且未經處置的高危及以

上的安全漏洞。注：處置方式包括消除漏洞、制定減緩措施等方式。

6

說明：本條款的說明參見第7章的相關說明。

（3）在線軟件升級時，車輛和在線升級服務器應進行身份認證，驗證其身份的真實性，

車載軟件升級系統應對下載的在線升級包進行真實性和完整性校驗，車載軟件升級系統應記

錄在線升級過程中發(fā)生的失敗事件日志。

說明：該條款是對在線軟件升級場景（OTA場景）提出的要求；在線升級包在解包和

分發(fā)之前，需要由車載軟件升級系統校驗其真實性和完整性，以保證在線升級包的真實來源

和未受修改，其他環(huán)節(jié)是否進行校驗不在本文件中進行要求。

（4）離線軟件升級時，若車輛使用車載軟件升級系統進行離線升級，車輛應對離線升

級包真實性和完整性進行校驗，若車輛不使用車載軟件升級系統進行離線升級，應采取保護

措施保證刷寫接入端的安全性，或者校驗離線升級包的真實性和完整性。

說明：若車輛不使用車載軟件升級系統進行離線升級，主要有以下兩類升級方式：a）

使用診斷儀等基于OBD端口的設備進行刷寫升級；b）使用USB端口進行直刷（不經過車

載軟件升級系統）。如果采用a）方式，要求車端刷寫準入端采用如27服務等防護措施對

診斷儀等設備進行認證之后，才能進行刷寫操作；如果采用b）方式，要求ECU在被刷寫

之前對離線升級包的真實性和完整性進行校驗。

第10章數據代碼安全要求

基于國內行業(yè)技術發(fā)展現狀，參考R155法規(guī)附錄5中的部分相關內容（表A14.3.6有關

脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B5、B7、C3中有關的緩解措施），針對

以下方面提出要求：

（1）車輛應安全的地存儲對稱密鑰和私鑰，防止其被非授權訪問和獲取。

說明：常見的安全的存儲方式包括存儲在HSM、SE、TEE等安全模塊，也包括安全的

軟件存儲形式。

（2）車輛應采取安全防御機制保護存儲在車內的車輛識別代號（VIN）和用于身份識

別的數據，防止其被非授權刪除和修改。

說明：此條要求中用于身份識別的數據由企業(yè)自行確定，包括直接用于身份識別的數據

和組合起來間接識別身份的數據。

（3）車輛應采取安全防御機制保護存儲在車內的關鍵數據，防止其被非授權刪除和修

改。

說明：關鍵數據由企業(yè)根據車型的業(yè)務場景和風險評估來確認。

（4）車輛應具備個人信息清除功能及防恢復機制，便于在轉售、租借或報廢時清除個

人信息。

說明：國家要求存儲在車內不允許修改的數據除外，例如DSSAD、EDR內存儲的數據，

防恢復機制在本標準中不提出強度要求，未來以數據安全標準要求的強度為準。

（5）車輛不得直接向境外傳輸數據。

7

說明：此條款主要是避免車型設計時預留了數據出境的功能或接口，導致大批量的車輛

避開管理部門的監(jiān)管向境外直傳數據。車輛通過國內云平臺中轉間接向境外傳遞數據，用戶

個人行為的跨境數據傳輸均不受本條款的要求。

附錄A（規(guī)范性）車輛信息安全要求測試驗證方法

對測試條件、測試輸入信息、車輛外部連接安全測試方法、車輛通信通道安全測試方法、

車輛軟件升級安全測試方法、車輛數據代碼安全測試方法等內容進行了規(guī)定，并分別與正文

第7章~第10章的要求條款進行對應，給出具體的通過條件。

（五）主要試驗（或）驗證情況分析

根據工作安排，中國汽車技術研究中心有限公司、工業(yè)和信息化部計算機與微電子發(fā)展

研究中心（中國軟件評測中心）、上海機動車檢測認證技術研究中心有限公司、中國汽車工

程研究院股份有限公司、招商局檢測車輛技術研究院有限公司、襄陽達安汽車檢測中心有限

公司等6家檢測機構以及上海汽車集團股份有限公司、重慶長安汽車股份有限公司、廣州汽

車集團股份有限公司、吉利汽車研究院（寧波）有限公司、東風汽車集團有限公司、上海蔚

來汽車有限公司、廣州小鵬汽車科技有限公司、北京車和家汽車科技有限公司、梅賽德斯-

奔馳集團股份公司、寶馬（中國）服務有限公司、一汽-大眾汽車有限公司、一汽解放汽車

有限公司等進行了汽車信息安全管理體系審核、車輛技術要求的試驗方法驗證，以下選擇有

代表性的驗證內容對驗證主要情況進行說明。

1.汽車信息安全管理體系審核評估結果

在審核期間，汽車生產企業(yè)依據秘書處發(fā)出的《體系審核表》進行材料準備，采取文件

展示、現場演示等方式，通過現場/遠程方式進行審核，評估企業(yè)是否滿足本標準草案中的

要求。經審核發(fā)現，所有參與驗證活動的整車生產企業(yè)均建立汽車信息安全管理體系框架，

初步形成面向汽車產品的信息安全管理制度，能夠覆蓋本標準第5章的條款要求，但不同企

業(yè)的落地執(zhí)行方式不同、所執(zhí)行顆粒度有所差異。為便于行業(yè)理解以及加強企業(yè)落地可操作

性，特作如下說明：

（1）車輛制造商應建立車輛全生命周期的信息安全管理體系。

說明：ISO21434《道路車輛信息安全工程》可作為證明和評估信息安全管理體系所需

階段的依據。第9章“概念階段”、第10章“產品開發(fā)”和第11章“信息安全驗證”可用于評估信

息安全管理體系的開發(fā)階段。第12章“生產”可用于評估信息安全管理體系的生產階段。第7

章“持續(xù)的信息安全活動”、第13章“操作和維護”以及第14章“報廢”可用于評估信息安全管理

體系的后生產階段；

（2）應建立企業(yè)內部管理信息安全的流程。

說明：本條款中提及的企業(yè)內部管理信息安全的流程，指在組織層級與車輛信息安全強

相關的流程，對于組織本身的信息安全流程，如：針對企業(yè)IT系統的信息安全管理流程等不

在本標準考慮范圍內。此外，本條款可參考ISO21434《道路車輛信息安全工程》中第五章

8

“組織信息安全管理”中的要求，從治理文化、信息共享、安全審核、工具管理、持續(xù)改進等

方面進行開展。

（3）應建立識別、評估、分類、處置車輛信息安全風險及核實已識別風險得到適當處

置的流程，并確保車輛風險評估保持最新狀態(tài)。

說明：本條款中提及的風險指車輛全生命周期中的信息安全風險，覆蓋研發(fā)階段、生產

階段、后生產階段。企業(yè)根據實際需求與業(yè)務場景，定義車輛全生命周期中的信息安全風險

管控流程。此外，ISO21434《道路車輛信息安全工程》中第十五章提及的威脅分析與風險

評估方法論可供參考，企業(yè)可自行選擇是否采用。

（4）應建立針對車輛的網絡攻擊、網絡威脅和漏洞的監(jiān)測和響應流程，要求如下：

a）應包含確保已識別的網絡威脅和漏洞得到響應，且在合理的時限內得到處置的流程；

說明：本條款中提及的“合理時限”當前可由企業(yè)結合實際情況自行定義，“處置”包括采

取緩解措施、修復、持續(xù)監(jiān)測等方式。

此外，此次審核發(fā)現：針對于合資企業(yè)和外資企業(yè)，其部分體系文檔（尤其是車輛產品

開發(fā)相關制度）保存在國外，且供應商來自于各個國家，在審核時存在無法提供資料或提供

的資料難以審查（非中英版本）的情況，需在標準中進行明確約束。

2.車輛信息安全一般要求評估結果

經審核評估發(fā)現，汽車生產企業(yè)針對部分新車型已開展信息安全活動，但由于車型項目

尚處于概念階段，無法依據所建立的汽車信息安全管理體系開展全部活動。且部分企業(yè)執(zhí)行

的信息安全活動與建立的流程規(guī)定并不一致?？紤]到目前汽車生產企業(yè)的信息安全管理體系

亦正處于建設過程中，需預留充足時間供其新款車型研發(fā)驗證。同時，在審核時發(fā)現，對于

風險評估活動而言，企業(yè)開展形式不一；對于供應商管理而言，汽車企業(yè)能夠提出明確的信

息安全技術要求，但針對于職責劃分、工作內容等，企業(yè)開展形式不一等等?？傮w來說，被

審核的汽車生產企業(yè)對于本標準的第六章條款要求理解無明顯偏差。

此外，由于合資企業(yè)屬性，車輛產品由國內外團隊共同完成，但國外團隊并不會向國內

團隊提供完整的風險評估和相關處置文檔，因此，存在車型產品開發(fā)完成后，但實際風險評

估不充分的可能性，車型產品的安全性存在較大風險。

3.車型技術要求試驗結果

測試開始前，需結合車輛信息安全一般要求的評估結果確認適用于該車型的測試項，并

獲取必要的測試輸入信息。

測試輸入信息并不一定需要提供完整的文本材料，車輛生產企業(yè)針對不同的測試輸入信

息可以采用不同的方式提供測試輸入，不同的測試輸入信息提供方式如下：

（1）測試人員和車輛生產企業(yè)技術人員通過會議溝通確認：測試車輛遠程控制功能，

包括遠程控制指令應用場景和使用權限；測試車輛授權第三方應用真實性和完整性驗證方式；

測試車輛非授權第三方應用的訪問控制機制；測試車輛外部接口；與測試車輛通信的車輛生

9

產企業(yè)云平臺；測試車輛通信方法，包括采用的通信協議類型；測試車輛V2X功能；測試車

輛向外傳輸敏感個人信息的通信通道；測試車輛與外部直接通信零部件；測試車輛個人信息

清除功能及防恢復機制。

（2）車輛生產企業(yè)技術人員先提供目錄清單，然后測試人員在車輛生產企業(yè)現場確認

測試必須的詳細信息：遠程控制指令審計方式及審計日志記錄地址、車輛記錄異常指令的地

址；測試車內通信方案及通信矩陣樣例，包括專用數據通信矩陣樣例；測試車輛對稱密鑰和

私鑰的存儲方式及說明文檔；測試車輛內部存儲敏感個人信息存儲地址；測試車輛內存儲的

車輛識別代號和用于身份識別的數據清單及存儲地址；測試車輛內存儲的關鍵數據清單及存

儲的地址。

（3）車輛生產企業(yè)安排技術人員攜帶相應的工具在檢測機構現場協助完成測試，測試

結束后工具收回：測試車輛車載軟件升級系統可信根、引導加載程序、系統固件的訪問方式

和地址；測試車輛實現離線軟件升級的方式及工具。

按照2021年10月項目組第6次會議形成的文件開展了驗證測試，不同車輛測試項目并不

完全相同（全覆蓋為80項測試項），下表中給出了標準驗證的總體情況。

序

標準條款通過情況不可行/未通過試驗主要原因

號

完成13項測試項的驗證，剩余2項測試項被GB

通過數量：11

34660-2017覆蓋未開展驗證試驗；

1外部連接安全要求不通過數量：2

13項測試項中有11項測試方法得到認可，2項測

對應15項測試項未試驗數量：2

試方法需進行調整。

完成33項測試項的驗證，剩余7項與V2X相關，由

通過數量：25于本次送檢車型均不具備V2X功能，未開展驗證

通信安全要求

2不通過數量：8試驗；

對應40項測試項

未試驗數量：733項中有25項測試方法得到了認可，8項測試方

法需要進行調整。

通過數量：7完成了全部測試項的驗證；

軟件升級安全要求

3不通過數量：613項測試項中有7項方法得到了認可，6項測試方

對應13項測試項

未試驗數量：0法需進行調整。

通過數量：11完成了全部測試項的驗證；

數據代碼安全要求

4不通過數量：112項測試項中有11項方法得到了認可，1項測試

對應12項測試項

未試驗數量：0方法需進行調整。

測試驗證情況總體總結及重點問題說明：

（1）車型流程審核是開展車型技術要求試驗驗證的基礎，車型技術要求試驗驗證是對

車型流程審核結果的補充確認。

（2）測試驗證時發(fā)現測試項可能無法完全覆蓋技術要求，若企業(yè)風險評估后的緩解措

施多于技術要求，多出來的企業(yè)自定義安全措施需進行評估確認，不再進行測試。

（3）部分測試方法可能會影響企業(yè)平臺運行。示例：標準原文-8.1.1.1車輛與車輛、

路邊單元、服務平臺等的通信，應實施身份認證。測試項-A.5.1.1.1.1與服務平臺通信的身

10

份認證試驗方法：

a)若車輛與服務平臺通信采用公有通信協議，采用網絡數據抓包工具進行數據抓包，

解析通信報文數據，檢查是否采用如TLSV1.2同等安全級別或以上要求的安全通信層協議；

b)若車輛與服務平臺通信采用私有通信協議，對私有通信協議方案進行審核，采用

網絡數據抓包的方法進行數據抓包，解析通信報文數據中加密密鑰衍生、更新及存儲策略，

檢查是否支持以安全方式進行定期更新，并以安全的方式存儲加密密鑰。

c)依據車輛端通信部件清單，使用車輛端設備和服務平臺的合法證書，檢測雙方是

否能夠完成身份認證以進行后續(xù)通信；

d)分別替換偽造的車輛端設備和服務平臺的證書，測試是否能夠通過身份認證并進

行后續(xù)通信。

說明：送檢車輛連接的平臺均為實際生產平臺，進行證書替換，采用私有APN通訊的認

證方式可能影響已售車輛運行。

（4）部分企業(yè)產品采取的防護技術可能會影響測試項執(zhí)行，將通過審核的方式補充證

明。示例：測試項-A.5.4.1車輛傳輸的機密數據保密性試驗/防止敏感信息泄露試驗。測試

人員應依據車輛傳輸機密數據清單，按照如下方法，檢驗測試車輛是否滿足正文8.4.1的要求：

a)抓取通訊數據包，檢查是否正確使用聲明的加密算法對車輛傳輸的機密數據進行

加密；

b)檢查使用的加密算法強度是否滿足需求。

說明：標準技術要求“8.1.1.1車輛與車輛、路側單元、服務平臺等的通信，應實施身

份認證”，企業(yè)為滿足此條款要求，采用了TLS1.2以上安全通訊協議時，測試人員無法通過

技術測試驗證的方式核查此時傳輸的數據消息體本身是否依照聲明的算法進行數據加密；

（5）通過本次標準驗證試驗，對部分測試方法進行優(yōu)化調整：

a)若基于第7-10章安全技術要求的風險處置措施與企業(yè)所識別的風險不相關，無需

對不相關的條款開展測試，僅需開展評估確認。

b)若基于第7-10章安全技術要求的風險處置措施無法覆蓋企業(yè)所識別的風險，應在

按照附錄A開展測試驗證的基礎上，對企業(yè)實際所使用的處置措施開展評估確認。

c)若基于第7-10章安全技術要求的風險處置措施適用于企業(yè)所識別的風險，按照附

錄A.4-A.7的要求開展驗證，其中適用于現場測試的條款依照文件中列出的條款開展測試進

行確認，不適用于現場測試的條款通過審核研發(fā)階段的第三方測試報告進行確認。

11

試驗驗證流程總結

三、與有關法律、行政法規(guī)和其他標準的關系

本標準是我國智能網聯汽車管理的重要內容；與現行相關法律、法規(guī)、規(guī)章及相關標準

沒有沖突或矛盾。

四、與國際標準化組織、其他國家或者地區(qū)有關法律法規(guī)和標準的比對分析

本標準未采用國際標準，基于國內行業(yè)發(fā)展現狀和管理需求自主制定。

2020年6月，聯合國世界車輛法規(guī)協調論壇（UNWP29）發(fā)布R155《關于信息安全和

信息安全管理體系的汽車型式批準統一規(guī)定》，在信息安全管理體