汽車整車信息安全技術(shù)要求編輯說明

《汽車整車信息安全技術(shù)要求》

（征求意見稿）編制說明

一、工作簡況

（一）任務(wù)來源

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

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

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

術(shù)要求》。

（二）主要工作過程

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

草項目組，確定中國汽車技術(shù)研究中心有限公司、國汽（北京）智能網(wǎng)聯(lián)汽車研究院有限公

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

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

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

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

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

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

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

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

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

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

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

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

為強制性國家標準項目。

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

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

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

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

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

成試驗方法。

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

輛技術(shù)要求及試驗方法驗證。

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

1

見協(xié)調(diào)會，形成意見處理結(jié)論。

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

1.項目組第一次會議

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

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

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

V字型的架構(gòu)來設(shè)計，需要和《汽車信息安全通用技術(shù)要求》的安全原則及需求相結(jié)合，綜

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

2.項目組第二次會議

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

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

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

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

下一步編制工作的分工進行了安排，由威脅分析與風險評估、外部訪問點安全、內(nèi)部網(wǎng)絡(luò)通

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

版草案。

3.項目組第三次會議

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

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

全、內(nèi)部網(wǎng)絡(luò)通信安全、基于業(yè)務(wù)的安全、基于功能的安全、數(shù)據(jù)安全要求等7個部分對各

章的編寫思路和遇到的問題進行了交流與討論，基于討論進一步協(xié)調(diào)統(tǒng)一了標準框架、編寫

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

4.項目組第四次會議

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

會議對本標準轉(zhuǎn)為強標的背景進行了介紹，增進項目組全體成員對現(xiàn)有標準內(nèi)容的理解；明

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

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

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

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

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

2021年7月，為貫徹落實《網(wǎng)絡(luò)安全法》《數(shù)據(jù)安全法》等，應(yīng)對智能網(wǎng)聯(lián)汽車信息

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

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

6.項目組第五次會議

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

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

2

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

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

一梳理標準內(nèi)容及行文。

7.項目組第六次會議

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

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

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

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

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

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

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

8.標準驗證試驗

2022年1月-6月，汽標委智能網(wǎng)聯(lián)汽車分標委秘書處根據(jù)標準編制工作計劃開展本標

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

步開展；車輛技術(shù)要求及試驗方法驗證，在相關(guān)試驗機構(gòu)開展。秘書處面向汽車信息安全標

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

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

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

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

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

經(jīng)驗和問題，進一步完善標準草案。

9.試驗工作專題啟動會

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

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

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

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

10.工作組意見協(xié)調(diào)會

2022年7月31日，形成工作組征求意見稿，并面向汽標委智能網(wǎng)聯(lián)汽車分標委汽車信

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

標準項目組于8月30日至9月6日召開意見處理協(xié)調(diào)會議，根據(jù)反饋意見進行了逐條討論

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

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

本文件編寫符合GB/T1.1—2020《標準化工作導(dǎo)則第1部分：標準化文件的結(jié)構(gòu)和

起草規(guī)則》的規(guī)定起草。起草過程，充分考慮國內(nèi)外現(xiàn)有相關(guān)標準的統(tǒng)一和協(xié)調(diào)；標準的要

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

3

（一）適用范圍

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

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

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

參考執(zhí)行。

（二）主要技術(shù)內(nèi)容

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

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

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

求：

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

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

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

相關(guān)話題，則不在本標準所要求的體系范圍內(nèi)。

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

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

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

等相關(guān)管控活動，并建立相應(yīng)的流程。此處的流程應(yīng)能夠應(yīng)對車輛全生命周期的風險管控，

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

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

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

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

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

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

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

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

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

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

（2）識別和管理車輛與供應(yīng)商相關(guān)的風險。

說明：此處“供應(yīng)商”關(guān)注與車輛產(chǎn)品風險相關(guān)的供應(yīng)商，包括合同供應(yīng)商、服務(wù)提供

商等。

（3）應(yīng)針對車輛實施相應(yīng)措施，以識別和防御針對該車輛的網(wǎng)絡(luò)攻擊、網(wǎng)絡(luò)威脅和漏

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

以及為分析網(wǎng)絡(luò)攻擊、網(wǎng)絡(luò)威脅和漏洞提供數(shù)據(jù)取證能力。

4

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

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

攻擊、網(wǎng)絡(luò)威脅和漏洞方面的監(jiān)測，并且支持數(shù)據(jù)取證。

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

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

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

方面提出要求：

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

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

操控功能系統(tǒng)的程序和配置數(shù)據(jù)的完整性驗證要求等。

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

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

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

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

安裝時進行提示、限制其訪問權(quán)限，避免非授權(quán)的第三方應(yīng)用對車輛系統(tǒng)等的資源配置、關(guān)

鍵參數(shù)、重要數(shù)據(jù)等進行訪問。

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

控制，禁止非授權(quán)訪問。應(yīng)對USB端口接入設(shè)備中的文件進行訪問控制，只允許指定格式的

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

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

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

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

方應(yīng)用等，應(yīng)不存在由權(quán)威漏洞平臺6個月前公布且未經(jīng)處置的高危及以上的安全漏洞，處

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

（5）對網(wǎng)絡(luò)端口的安全要求，應(yīng)關(guān)閉不必要網(wǎng)絡(luò)端口，如TCP連接或UDP消息的邏輯

信道端點等。

第8章車輛通信安全要求

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

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

方面提出要求：

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

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

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

性的驗證。

5

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

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

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

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

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

求。

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

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

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

（5）車輛與外部直接通信的零部件應(yīng)具備安全機制防止非授權(quán)的系統(tǒng)特權(quán)訪問。

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

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

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

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

（6）車輛應(yīng)具有識別惡意的V2X數(shù)據(jù)、惡意的診斷數(shù)據(jù)、惡意的專有數(shù)據(jù)等的能力，

并采取防護措施。

說明：惡意的診斷數(shù)據(jù)包括非法診斷請求、非法診斷應(yīng)答、暴力請求認證、非法開啟

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

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

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

（7）車輛應(yīng)對關(guān)鍵的通信信息安全事件進行日志記錄。

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

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

第9章軟件升級安全要求

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

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

如下方面提出要求：

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

引導(dǎo)加載程序、系統(tǒng)固件不被篡改，或被篡改后無法正常啟動。

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

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

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

（2）車載軟件升級系統(tǒng)應(yīng)不存在由權(quán)威漏洞平臺6個月前公布且未經(jīng)處置的高危及以

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

6

說明：本條款的說明參見第7章的相關(guān)說明。

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

車載軟件升級系統(tǒng)應(yīng)對下載的在線升級包進行真實性和完整性校驗，車載軟件升級系統(tǒng)應(yīng)記

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

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

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

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

（4）離線軟件升級時，若車輛使用車載軟件升級系統(tǒng)進行離線升級，車輛應(yīng)對離線升

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

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

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

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

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

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

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

第10章數(shù)據(jù)代碼安全要求

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

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

以下方面提出要求：

（1）車輛應(yīng)安全的地存儲對稱密鑰和私鑰，防止其被非授權(quán)訪問和獲取。

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

軟件存儲形式。

（2）車輛應(yīng)采取安全防御機制保護存儲在車內(nèi)的車輛識別代號（VIN）和用于身份識

別的數(shù)據(jù)，防止其被非授權(quán)刪除和修改。

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

和組合起來間接識別身份的數(shù)據(jù)。

（3）車輛應(yīng)采取安全防御機制保護存儲在車內(nèi)的關(guān)鍵數(shù)據(jù)，防止其被非授權(quán)刪除和修

改。

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

（4）車輛應(yīng)具備個人信息清除功能及防恢復(fù)機制，便于在轉(zhuǎn)售、租借或報廢時清除個

人信息。

說明：國家要求存儲在車內(nèi)不允許修改的數(shù)據(jù)除外，例如DSSAD、EDR內(nèi)存儲的數(shù)據(jù)，

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

（5）車輛不得直接向境外傳輸數(shù)據(jù)。

7

說明：此條款主要是避免車型設(shè)計時預(yù)留了數(shù)據(jù)出境的功能或接口，導(dǎo)致大批量的車輛

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

代表性的驗證內(nèi)容對驗證主要情況進行說明。

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

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

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

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

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

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

性，特作如下說明：

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

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

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

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

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

體系的后生產(chǎn)階段；

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

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

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

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

8

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

方面進行開展。

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

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

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

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

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

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

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

a）應(yīng)包含確保已識別的網(wǎng)絡(luò)威脅和漏洞得到響應(yīng)，且在合理的時限內(nèi)得到處置的流程；

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

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

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

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

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

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

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

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

的信息安全活動與建立的流程規(guī)定并不一致。考慮到目前汽車生產(chǎn)企業(yè)的信息安全管理體系

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

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

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

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

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

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

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

3.車型技術(shù)要求試驗結(jié)果

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

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

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

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

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

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

測試車輛非授權(quán)第三方應(yīng)用的訪問控制機制；測試車輛外部接口；與測試車輛通信的車輛生

9

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

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

清除功能及防恢復(fù)機制。

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

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

址；測試車內(nèi)通信方案及通信矩陣樣例，包括專用數(shù)據(jù)通信矩陣樣例；測試車輛對稱密鑰和

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

車輛識別代號和用于身份識別的數(shù)據(jù)清單及存儲地址；測試車輛內(nèi)存儲的關(guān)鍵數(shù)據(jù)清單及存

儲的地址。

（3）車輛生產(chǎn)企業(yè)安排技術(shù)人員攜帶相應(yīng)的工具在檢測機構(gòu)現(xiàn)場協(xié)助完成測試，測試

結(jié)束后工具收回：測試車輛車載軟件升級系統(tǒng)可信根、引導(dǎo)加載程序、系統(tǒng)固件的訪問方式

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

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

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

序

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

號

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

通過數(shù)量：11

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

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

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

對應(yīng)15項測試項未試驗數(shù)量：2

試方法需進行調(diào)整。

完成33項測試項的驗證，剩余7項與V2X相關(guān)，由

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

通信安全要求

2不通過數(shù)量：8試驗；

對應(yīng)40項測試項

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

法需要進行調(diào)整。

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

軟件升級安全要求

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

對應(yīng)13項測試項

未試驗數(shù)量：0法需進行調(diào)整。

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

數(shù)據(jù)代碼安全要求

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

對應(yīng)12項測試項

未試驗數(shù)量：0方法需進行調(diào)整。

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

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

車型流程審核結(jié)果的補充確認。

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

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

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

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

10

份認證試驗方法：

a)若車輛與服務(wù)平臺通信采用公有通信協(xié)議，采用網(wǎng)絡(luò)數(shù)據(jù)抓包工具進行數(shù)據(jù)抓包，

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

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

網(wǎng)絡(luò)數(shù)據(jù)抓包的方法進行數(shù)據(jù)抓包，解析通信報文數(shù)據(jù)中加密密鑰衍生、更新及存儲策略，

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

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

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

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

行后續(xù)通信。

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

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

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

明。示例：測試項-A.5.4.1車輛傳輸?shù)臋C密數(shù)據(jù)保密性試驗/防止敏感信息泄露試驗。測試

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

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

加密；

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

說明：標準技術(shù)要求“8.1.1.1車輛與車輛、路側(cè)單元、服務(wù)平臺等的通信，應(yīng)實施身

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

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

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

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

對不相關(guān)的條款開展測試，僅需開展評估確認。

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

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

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

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

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

11

試驗驗證流程總結(jié)

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

本標準是我國智能網(wǎng)聯(lián)汽車管理的重要內(nèi)容；與現(xiàn)行相關(guān)法律、法規(guī)、規(guī)章及相關(guān)標準

沒有沖突或矛盾。

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

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

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

信息安全管理體系的汽車型式批準統(tǒng)一規(guī)定》，在信息安全管理體系的符合性證明、信息安

全管理體系要求、車型要求、車型修改及擴展、生產(chǎn)一致性等方面做出規(guī)定，并在其附錄中

給出了主要的汽車信息安全風險及緩解措施。該法規(guī)已于2021年1月1日生效，歐盟、日

本等計劃從2022年7月起，所有新車型需要滿足R155法規(guī)，以獲取車輛型式批準WVTA

（WholeVehicleTypeApproval）證書后上市銷售，計劃2024年7月起制造的所有車輛均

必須滿足R155法規(guī)的要求。

本標準的制定借鑒聯(lián)合國世界車輛法規(guī)協(xié)調(diào)論壇(UNWP29)已發(fā)布《關(guān)于信息安全和信

息安全管理體系的汽車型式批準統(tǒng)一規(guī)定》法規(guī)的思路，在滿足政府管理需求和符合行業(yè)發(fā)

展現(xiàn)狀的基礎(chǔ)上自主制定。

五、重大分歧意見的處理過程、處理意見及其依據(jù)

本標準修訂過程中無重大分歧。

六、對強制性國家標準自發(fā)布日期至實施日期之間的過渡期的建議及理由

由于汽車信息安全管理體系及信息安全技術(shù)的應(yīng)用涉及企業(yè)管理體系構(gòu)建、車輛安全設(shè)

計開發(fā)、檢測機構(gòu)試驗開展等問題，建議本標準自發(fā)布日期至實施日期之間給予12個月過

渡期。

本標準的實施日期為：

對于新申請型式批準的車型，自本文件實施之日起開始執(zhí)行。

12

對于已獲得型式批準的車型，自本文件實施之日起第25個月開始執(zhí)行。

七、與實施強制性國家標準有關(guān)的政策措施

本標準的實施監(jiān)督管理部門是工業(yè)和信息化部。對于違反強制

性國家標準的行為，應(yīng)按照下列法律、行政法規(guī)、部門規(guī)章相關(guān)規(guī)定進行處理：

（一）《中華人民共和國標準化法(2017修訂)》

第二十五條不符合強制性標準的產(chǎn)品、服務(wù)，不得生產(chǎn)、銷售、進口或者提供。

第三十六條生產(chǎn)、銷售、進口產(chǎn)品或者提供服務(wù)不符合強制性標準，或者企業(yè)生產(chǎn)的

產(chǎn)品、提供的服務(wù)不符合其公開標準的技術(shù)要求的，依法承擔民事責任。

（二）《中華人民共和國產(chǎn)品質(zhì)量法（2018年修訂）》

第十三條可能危及人體健康和人身、財產(chǎn)安全的工業(yè)產(chǎn)品，必須符合保障人體健康和

人身、財產(chǎn)安全的國家標準、行業(yè)標準；未制定國家標準、行業(yè)標準的，必須符合保障人體

健康和人身、財產(chǎn)安全的要求。

禁止生產(chǎn)、銷售不符合保障人體健康和人身、財產(chǎn)安全的標準和要求的工業(yè)產(chǎn)品。具體

管理辦法由國務(wù)院規(guī)定。

（三）工業(yè)和信息化部《車輛生產(chǎn)企業(yè)及產(chǎn)品生產(chǎn)一致性監(jiān)督管理辦法》（工產(chǎn)業(yè)〔2010〕

第109號）

第十條對于不能保證產(chǎn)品生產(chǎn)一致性的車輛生產(chǎn)企業(yè)，工業(yè)和信息化部將視情節(jié)輕重，

依法分別采取通報、限期整改、暫?；虺蜂N“免予安全技術(shù)檢驗”備案、暫停或撤銷其相關(guān)

產(chǎn)品《公告》等措施。

八、是否需要對外通報的建議及理由

本標準為強制性國家標準，在標準適用范圍為M類和N類及至少裝有1個電子控制單

元的O類汽車，涉及進口車，需對外通報。

九、廢止現(xiàn)行有關(guān)標準的建議

無。

十、涉及專利的有關(guān)說明

本標準不涉及專利。

十一、強制性國家標準所涉及的產(chǎn)品、過程或者服務(wù)目錄

本標準涉及產(chǎn)品包括M類和N類及至少裝有1個電子控制單元的O類汽車。

十二、其他應(yīng)當予以說明的事項

無。

13

《汽車整車信息安全技術(shù)要求》

（征求意見稿）編制說明

一、工作簡況

（一）任務(wù)來源

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

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

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

術(shù)要求》。

（二）主要工作過程

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

草項目組，確定中國汽車技術(shù)研究中心有限公司、國汽（北京）智能網(wǎng)聯(lián)汽車研究院有限公

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

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

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

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

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

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

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

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

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

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

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

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

為強制性國家標準項目。

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

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

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

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

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

成試驗方法。

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

輛技術(shù)要求及試驗方法驗證。

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

1

見協(xié)調(diào)會，形成意見處理結(jié)論。

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

1.項目組第一次會議

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

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

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

V字型的架構(gòu)來設(shè)計，需要和《汽車信息安全通用技術(shù)要求》的安全原則及需求相結(jié)合，綜

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

2.項目組第二次會議

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

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

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

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

下一步編制工作的分工進行了安排，由威脅分析與風險評估、外部訪問點安全、內(nèi)部網(wǎng)絡(luò)通

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

版草案。

3.項目組第三次會議

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

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

全、內(nèi)部網(wǎng)絡(luò)通信安全、基于業(yè)務(wù)的安全、基于功能的安全、數(shù)據(jù)安全要求等7個部分對各

章的編寫思路和遇到的問題進行了交流與討論，基于討論進一步協(xié)調(diào)統(tǒng)一了標準框架、編寫

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

4.項目組第四次會議

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

會議對本標準轉(zhuǎn)為強標的背景進行了介紹，增進項目組全體成員對現(xiàn)有標準內(nèi)容的理解；明

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

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

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

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

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

2021年7月，為貫徹落實《網(wǎng)絡(luò)安全法》《數(shù)據(jù)安全法》等，應(yīng)對智能網(wǎng)聯(lián)汽車信息

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

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

6.項目組第五次會議

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

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

2

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

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

一梳理標準內(nèi)容及行文。

7.項目組第六次會議

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

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

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

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

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

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

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

8.標準驗證試驗

2022年1月-6月，汽標委智能網(wǎng)聯(lián)汽車分標委秘書處根據(jù)標準編制工作計劃開展本標

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

步開展；車輛技術(shù)要求及試驗方法驗證，在相關(guān)試驗機構(gòu)開展。秘書處面向汽車信息安全標

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

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

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

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

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

經(jīng)驗和問題，進一步完善標準草案。

9.試驗工作專題啟動會

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

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

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

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

10.工作組意見協(xié)調(diào)會

2022年7月31日，形成工作組征求意見稿，并面向汽標委智能網(wǎng)聯(lián)汽車分標委汽車信

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

標準項目組于8月30日至9月6日召開意見處理協(xié)調(diào)會議，根據(jù)反饋意見進行了逐條討論

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

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

本文件編寫符合GB/T1.1—2020《標準化工作導(dǎo)則第1部分：標準化文件的結(jié)構(gòu)和

起草規(guī)則》的規(guī)定起草。起草過程，充分考慮國內(nèi)外現(xiàn)有相關(guān)標準的統(tǒng)一和協(xié)調(diào)；標準的要

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

3

（一）適用范圍

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

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

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

參考執(zhí)行。

（二）主要技術(shù)內(nèi)容

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

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

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

求：

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

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

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

相關(guān)話題，則不在本標準所要求的體系范圍內(nèi)。

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

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

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

等相關(guān)管控活動，并建立相應(yīng)的流程。此處的流程應(yīng)能夠應(yīng)對車輛全生命周期的風險管控，

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

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

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

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

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

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

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

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

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

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

（2）識別和管理車輛與供應(yīng)商相關(guān)的風險。

說明：此處“供應(yīng)商”關(guān)注與車輛產(chǎn)品風險相關(guān)的供應(yīng)商，包括合同供應(yīng)商、服務(wù)提供

商等。

（3）應(yīng)針對車輛實施相應(yīng)措施，以識別和防御針對該車輛的網(wǎng)絡(luò)攻擊、網(wǎng)絡(luò)威脅和漏

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

以及為分析網(wǎng)絡(luò)攻擊、網(wǎng)絡(luò)威脅和漏洞提供數(shù)據(jù)取證能力。

4

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

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

攻擊、網(wǎng)絡(luò)威脅和漏洞方面的監(jiān)測，并且支持數(shù)據(jù)取證。

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

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

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

方面提出要求：

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

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

操控功能系統(tǒng)的程序和配置數(shù)據(jù)的完整性驗證要求等。

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

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

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

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

安裝時進行提示、限制其訪問權(quán)限，避免非授權(quán)的第三方應(yīng)用對車輛系統(tǒng)等的資源配置、關(guān)

鍵參數(shù)、重要數(shù)據(jù)等進行訪問。

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

控制，禁止非授權(quán)訪問。應(yīng)對USB端口接入設(shè)備中的文件進行訪問控制，只允許指定格式的

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

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

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

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

方應(yīng)用等，應(yīng)不存在由權(quán)威漏洞平臺6個月前公布且未經(jīng)處置的高危及以上的安全漏洞，處

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

（5）對網(wǎng)絡(luò)端口的安全要求，應(yīng)關(guān)閉不必要網(wǎng)絡(luò)端口，如TCP連接或UDP消息的邏輯

信道端點等。

第8章車輛通信安全要求

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

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

方面提出要求：

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

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

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

性的驗證。

5

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

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

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

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

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

求。

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

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

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

（5）車輛與外部直接通信的零部件應(yīng)具備安全機制防止非授權(quán)的系統(tǒng)特權(quán)訪問。

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

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

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

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

（6）車輛應(yīng)具有識別惡意的V2X數(shù)據(jù)、惡意的診斷數(shù)據(jù)、惡意的專有數(shù)據(jù)等的能力，

并采取防護措施。

說明：惡意的診斷數(shù)據(jù)包括非法診斷請求、非法診斷應(yīng)答、暴力請求認證、非法開啟

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

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

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

（7）車輛應(yīng)對關(guān)鍵的通信信息安全事件進行日志記錄。

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

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

第9章軟件升級安全要求

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

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

如下方面提出要求：

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

引導(dǎo)加載程序、系統(tǒng)固件不被篡改，或被篡改后無法正常啟動。

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

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

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

（2）車載軟件升級系統(tǒng)應(yīng)不存在由權(quán)威漏洞平臺6個月前公布且未經(jīng)處置的高危及以

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

6

說明：本條款的說明參見第7章的相關(guān)說明。

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

車載軟件升級系統(tǒng)應(yīng)對下載的在線升級包進行真實性和完整性校驗，車載軟件升級系統(tǒng)應(yīng)記

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

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

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

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

（4）離線軟件升級時，若車輛使用車載軟件升級系統(tǒng)進行離線升級，車輛應(yīng)對離線升

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

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

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

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

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

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

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

第10章數(shù)據(jù)代碼安全要求

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

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

以下方面提出要求：

（1）車輛應(yīng)安全的地存儲對稱密鑰和私鑰，防止其被非授權(quán)訪問和獲取。

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

軟件存儲形式。

（2）車輛應(yīng)采取安全防御機制保護存儲在車內(nèi)的車輛識別代號（VIN）和用于身份識

別的數(shù)據(jù)，防止其被非授權(quán)刪除和修改。

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

和組合起來間接識別身份的數(shù)據(jù)。

（3）車輛應(yīng)采取安全防御機制保護存儲在車內(nèi)的關(guān)鍵數(shù)據(jù)，防止其被非授權(quán)刪除和修

改。

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

（4）車輛應(yīng)具備個人信息清除功能及防恢復(fù)機制，便于在轉(zhuǎn)售、租借或報廢時清除個

人信息。

說明：國家要求存儲在車內(nèi)不允許修改的數(shù)據(jù)除外，例如DSSAD、EDR內(nèi)存儲的數(shù)據(jù)，

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

（5）車輛不得直接向境外傳輸數(shù)據(jù)。

7

說明：此條款主要是避免車型設(shè)計時預(yù)留了數(shù)據(jù)出境的功能或接口，導(dǎo)致大批量的車輛

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

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

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

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

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

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

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

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

研究中心（中國軟件評測中心）、上海機動