《汽車整車信息安全技術要求》（征求意見稿）編制說明一、工作簡況（一）任務來源根據國家標準化管理委員會《關于下達<包裝機械安全要求>等31項強制性國家標準制修訂計劃及相關標準外文版計劃的通知》（國標委發〔2021〕27號）中項目編號20214422-Q-339的強制性國家標準制定項目，制定強制性國家標準《汽車整車信息安全技術要求》。（二）主要工作過程受工業和信息化部委托，全國汽標委智能網聯汽車分標委根據單位申請情況成立標準起草項目組，確定中國汽車技術研究中心有限公司、國汽（北京）智能網聯汽車研究院有限公司和電子科技大學為標準起草項目組牽頭單位，并在此基礎上明確了任務和分工，積極開展標準的預研、起草及征求意見等工作。自標準制定工作啟動以來，牽頭單位多次組織項目組成員單位召開項目組會議，分析了聯合國等國際標準法規組織的汽車標準法規現狀，討論確定了適應中國汽車產業發展現狀的汽車整車信息安全的技術要求并編寫了標準草案，最終完成了標準的征求意見稿。2019年11月啟動標準編制工作，成立項目組，召開第1次會議。2019年12月就標準邊界及制定思路等內容征集各單位意見。2020年3月項目組第2次會議（線上），圍繞制定思路及框架展開討論。2020年4月～5月確定框架、征求參編意向并分工編寫。2020年6月～9月形成標準草案并提交立項申請。2020年10月項目組第3次會議，持續完善標準草案。2021年3月～4月根據行業管理需求和主管部門要求，將原推薦性國家標準項目調整為強制性國家標準項目。2021年4月項目組第4次會議，完成本標準與UNWP29R155法規的對比分析。2021年5月～7月組織多次封閉寫稿和專題研討會議，持續完善標準草案。2021年7月項目組第5次會議，充分參照R155法規及解釋文件形成標準草案。2021年8月～9月組織多次封閉寫稿和專題研討會議，持續完善標準草案。2021年10月項目組第6次會議，對草案進行詳細討論，確定技術要求框架，形成試驗方法。2022年1月～6月組織行業開展標準驗證試驗工作，包括企業信息安全管理審核、車輛技術要求及試驗方法驗證。2022年7月～8月在汽車信息安全標準工作組進行征集意見，收集反饋意見并召開意見協調會，形成意見處理結論。2022年9月根據意見反饋修改形成公開征求意見稿和編制說明。項目組第一次會議汽車整車信息安全技術要求標準項目組第一次會議于2019年11月5日在杭州召開，正式啟動標準制定工作。會議就標準的制定背景、范圍、目標、框架、進度計劃、研制思路等進行了討論，對一些共性問題進行了探討，會議明確標準撰寫的整體思路按照整車開發流程V字型的架構來設計，需要和《汽車信息安全通用技術要求》的安全原則及需求相結合，綜合考慮標準的對象，并在會后對標準框架開展進一步總結與梳理。項目組第二次會議汽車整車信息安全技術要求標準項目組第二次工作會議于2020年3月4日在線上召開，會議進一步圍繞標準背景及項目計劃、編寫思路、框架等展開討論。會議明確了標準定位是從整車視角出發綜合考量，不包括對零部件單獨的安全要求，技術要求和測試對象以整車為主；標準不區分不同的駕駛自動化級別，而是適用于道路車輛的通用基本要求。會議就標準下一步編制工作的分工進行了安排，由威脅分析與風險評估、外部訪問點安全、內部網絡通信安全、基于業務的安全、基于功能的安全、數據安全要求等7個部分分工編寫，形成V1.0版草案。項目組第三次會議汽車整車信息安全技術要求標準項目組第三次工作會議于2020年10月21日在北京召開。會議討論了標準的總體框架、編制思路，并由整車威脅分析與風險評估、外部訪問點安全、內部網絡通信安全、基于業務的安全、基于功能的安全、數據安全要求等7個部分對各章的編寫思路和遇到的問題進行了交流與討論，基于討論進一步協調統一了標準框架、編寫方式及要求力度等，并在會后面向項目組內廣泛征集各章節的編寫意見。項目組第四次會議汽車整車信息安全技術要求標準項目組第四次工作會議于2021年4月26日在天津召開。會議對本標準轉為強標的背景進行了介紹，增進項目組全體成員對現有標準內容的理解；明確了整體的時間進度計劃、各節點任務，明確各章節任務分工、工作思路和計劃。會議明確本標準作為國家強制標準，不一定代表技術先進性，而側重考量技術的廣泛性和通用性，每條技術要求的提出都應力求必要、精簡凝練，并且要著重考慮與UNR155法規的國際協調；圍繞法規原文對標準框架設置和章節內容進行了對應的優化與調整。作為強制性國家標準重新立項2021年7月，為貫徹落實《網絡安全法》《數據安全法》等，應對智能網聯汽車信息安全風險與挑戰，主管部門出于產業安全發展及行業管理需要，將該推薦性國家標準項目調整為強制性國家標準項目，為保障產業健康可持續發展劃定信息安全基線要求。項目組第五次會議汽車整車信息安全技術要求標準項目組第五次工作會議于2021年7月26-29日在廈門召開。本次會議擴大了項目組成員的參與范圍，主要針對車輛技術要求部分進行封閉寫稿及討論，并就各章節內容的編寫情況逐一進行介紹和全體討論，基本確定了標準的框架及主體內容，形成V2.0版草案，并參考GB40050等信息安全行業重點標準的行文表述方式，統一梳理標準內容及行文。項目組第六次會議汽車整車信息安全技術要求標準項目組第六次工作會議于2021年10月12-13日在成都召開。本次會議在項目組內對標準的技術要求條款進行逐條地討論、完善及確認，并初步討論了管理章節的內容及試驗開展的思路，為試驗方法編寫提供參考。會議形成的標準草案V3.0版，主要包括管理要求、車型技術要求、試驗方法3大部分內容，同時，明確了本標準不提出唯一限定的技術要求和試驗方法，希望企業在充分的風險評估的基礎上開展。后續將重點解決各章節存在內容交叉、重復的問題，進一步優化完善技術要求，增加相應的試驗方法，部署標準驗證試驗工作。標準驗證試驗2022年1月-6月，汽標委智能網聯汽車分標委秘書處根據標準編制工作計劃開展本標準驗證試驗，驗證試驗項目包括：汽車信息安全管理體系審核，在申請企業所在地及線上同步開展；車輛技術要求及試驗方法驗證，在相關試驗機構開展。秘書處面向汽車信息安全標準工作組廣泛征集參與企業及試驗車輛，由于本標準試驗驗證條款數量較多、準備工作復雜、體系驗證需大量相關方配合、整體試驗周期較長、試驗驗證資源有限，按照整車產品安全開發程度及企業信息安全管理體系建設完備程度，從征集到的24家汽車生產企業中最終選取了12家企業隨機分配至6家檢測機構共同開展驗證試驗。受疫情影響，以線上線下相結合的方式先后完成所有車輛的標準驗證試驗及信息安全管理體系審核工作，總結試驗過程中的經驗和問題，進一步完善標準草案。試驗工作專題啟動會汽車整車信息安全技術要求的試驗工作專題啟動會于2022年3月1日以線上會議召開。本次會議由秘書處及6家試驗機構共同參與，本次會議部署了開展驗證試驗的工作要求，并重點研討確定標準驗證試驗實施方案及具體工作計劃。明確了以驗證標準草案中各條要求的合理性和可實施性為出發點，核查標準要求是否為基線要求。工作組意見協調會2022年7月31日，形成工作組征求意見稿，并面向汽標委智能網聯汽車分標委汽車信息安全標準工作組100余家單位征求意見。本次反饋意見共計收到78家單位的意見反饋，標準項目組于8月30日至9月6日召開意見處理協調會議，根據反饋意見進行了逐條討論處理，并根據相關意見對標準公開征求意見稿和編制說明進行了修改。二、編制原則、強制性國家標準主要技術要求的依據及理由本文件編寫符合GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起草。起草過程，充分考慮國內外現有相關標準的統一和協調；標準的要求充分考慮了國內當前的行業技術水平，對草案內容進行多次征求意見和充分討論。（一）適用范圍本文件規定了汽車信息安全管理體系要求、車輛信息安全一般要求、車輛信息安全技術要求、審核評估及測試驗證方法。本文件適用于M類、N類及至少裝有1個電子控制單元的O類車輛，其他類型車輛可參考執行。（二）主要技術內容本標準主要技術內容包括6個部分，以下選擇標準技術要求的部分重點內容進行說明：第5章信息安全管理體系要求基于國內行業技術發展現狀，參考R155法規第7.2章節的內容，針對如下方面提出要求：車輛制造商應建立車輛全生命周期的信息安全管理體系。說明：本標準條款所要求的信息安全管理體系以車輛產品為核心，應覆蓋車輛的全生命周期。若流程、規定等僅與企業經營管理、組織自身運營相關，并不涉及車輛產品信息安全相關話題，則不在本標準所要求的體系范圍內。應建立識別、評估、分類、處置車輛信息安全風險及核實已識別風險得到適當處置的流程，并確保車輛風險評估保持最新狀態。說明：本條款要求汽車生產企業針對車輛的信息安全風險進行識別、評估、分類、處置等相關管控活動，并建立相應的流程。此處的流程應能夠應對車輛全生命周期的風險管控，企業可自行定義實施路線。應包含漏洞管理機制，明確漏洞收集、分析、報告、處置、發布等活動環節。說明：本條款明確要求企業建立漏洞管理機制，并且需涵蓋收集、分析、報告、處置、發布等關鍵環節。第6章車輛信息安全一般要求基于國內行業技術發展現狀，參考R155法規中第7.3章節的內容，及附錄5中的部分相關內容（表A14.3.4、4.3.7有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B3、B5中有關的緩解措施），針對如下方面提出要求：車輛產品開發流程應遵循汽車信息安全管理體系要求。說明：車輛產品應按照汽車信息安全管理體系中定義的相關流程、制度開展開發工作。識別和管理車輛與供應商相關的風險。說明：此處“供應商”關注與車輛產品風險相關的供應商，包括合同供應商、服務提供商等。應針對車輛實施相應措施，以識別和防御針對該車輛的網絡攻擊、網絡威脅和漏洞，并為車輛生產企業在識別與車輛相關的網絡攻擊、網絡威脅和漏洞方面提供監測能力，以及為分析網絡攻擊、網絡威脅和漏洞提供數據取證能力。說明：車輛產品端應實施相應的措施，與企業在汽車信息安全管理體系中建立的網絡攻擊、網絡威脅和漏洞的監測和響應流程進行協同，從而保障企業可以針對車輛產品進行網絡攻擊、網絡威脅和漏洞方面的監測，并且支持數據取證。第7章車輛外部連接安全要求基于國內行業技術發展現狀，參考R155法規附錄5中的相關內容（表A14.3.1、4.3.5有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B4中有關的緩解措施），針對如下方面提出要求：對具備遠程控制功能系統的安全要求，包括對遠程控制指令信息的真實性和完整性驗證、驗證失敗的處理功能、對遠程控制指令設置訪問控制、安全日志記錄、對車端遠程操控功能系統的程序和配置數據的完整性驗證要求等。對第三方應用安裝運行的要求，第三方應用是指汽車制造商及其供應商之外的其他法人實體提供的面向用戶提供服務的應用程序，包括通過應用商店或瀏覽器或USB等用戶安裝的應用軟件，汽車制造商應對其授權和認可的第三方應用的真實性和完整性進行驗證，防止該應用被篡改；汽車制造商應對其未授權的第三方應用的安裝運行采取防護措施，如在安裝時進行提示、限制其訪問權限，避免非授權的第三方應用對車輛系統等的資源配置、關鍵參數、重要數據等進行訪問。對外部接口的安全要求，包括對USB接口、診斷接口和其他接口的設備進行訪問控制，禁止非授權訪問。應對USB端口接入設備中的文件進行訪問控制，只允許指定格式的文件讀寫或指定簽名的應用軟件安裝或執行，應具備USB端口接入設備中病毒程序或攜帶病毒的媒體文件/應用軟件的鑒別并禁止安裝的能力，對通過診斷接口發送的對車輛關鍵參數寫操作請求時，進行身份鑒別、訪問控制等安全策略。對車輛外部連接系統漏洞管理的要求，包括但不限于遠程控制系統、授權的第三方應用等，應不存在由權威漏洞平臺6個月前公布且未經處置的高危及以上的安全漏洞，處置措施包括消除漏洞、制定減緩措施等。對網絡端口的安全要求，應關閉不必要網絡端口，如TCP連接或UDP消息的邏輯信道端點等。第8章車輛通信安全要求基于國內行業技術發展現狀，參考R155法規附錄5中的相關內容（表A14.3.2有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B1、B5中有關的緩解措施），針對如下方面提出要求：車輛與車輛生產企業云平臺通信時，應對其通信對象的身份真實性進行驗證。說明：本文件并未強制要求雙向認證、也未強制要求必須使用證書保護機制。車輛與車輛、路側單元、移動終端等進行直連通信時，應進行證書有效性和合法性的驗證。說明：本條款主要是針對V2X場景提出的要求。車輛應采用完整性保護機制保護外部通信通道。說明：本條款主要針對能夠在通信協議層面實現完整性保護機制的外部通信通道。某些外部通信通道例如RFID、NFC等，不適用此條款；無線傳感器與車載設備之間的通信、語音交互也不適用于本條款；對于企業采用的完整性保護技術類型和強度，本文件不做具體要求。應對車輛發送的敏感個人信息實施保密性保護。說明：本文件旨在對車輛的信息安全風險提出安全要求，具體“敏感個人信息”的定義以汽車數據安全相關管理要求和標準規定為準。車輛與外部直接通信的零部件應具備安全機制防止非授權的系統特權訪問。說明：本條款僅包含與外部直接通信的零部件，利用T-BOX，車載信息交互系統間接與外部通信的零部件不適用于本條款的要求；射頻、NFC等短距離無線通信的傳感器也不適用于本條款要求；身份識別機制包括基于密碼的認證機制、DTC記錄、日志記錄、異常提醒等，對外部通信零部件進行身份識別的技術可通過云端來實現。車輛應具有識別惡意的V2X數據、惡意的診斷數據、惡意的專有數據等的能力，并采取防護措施。說明：惡意的診斷數據包括非法診斷請求、非法診斷應答、暴力請求認證、非法開啟DTC主動上傳、惡意連續復位等；本條款使用“數據”而不是消息或指令等表述方式，是為了全文統一考慮，其本身是廣義的概念，可指代原文的“惡意消息”具；體惡意數據的定義由廠家決定并提供清單作為測試的輸入。車輛應對關鍵的通信信息安全事件進行日志記錄。說明：本條款對車輛通信信息安全事件日志記錄提出了要求，安全日志防護應滿足第10章數據代碼章節的要求。第9章軟件升級安全要求基于國內行業技術發展現狀，參考R155法規附錄5以及R156法規中的相關內容（表A14.3.3有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B2中有關的緩解措施），針對如下方面提出要求：車載軟件升級系統應具備安全啟動的功能，應保護車載軟件升級系統的可信根、引導加載程序、系統固件不被篡改，或被篡改后無法正常啟動。說明：車載軟件升級系統在行業和某些企業也被稱為車端OTAMaster，包括系統軟件和硬件；該條款的正常啟動是指車載軟件升級系統默認加載程序的啟動；本文件中將除默認加載程序的啟動之外，均視為非正常啟動。車載軟件升級系統應不存在由權威漏洞平臺6個月前公布且未經處置的高危及以上的安全漏洞。注：處置方式包括消除漏洞、制定減緩措施等方式。說明：本條款的說明參見第7章的相關說明。在線軟件升級時，車輛和在線升級服務器應進行身份認證，驗證其身份的真實性，車載軟件升級系統應對下載的在線升級包進行真實性和完整性校驗，車載軟件升級系統應記錄在線升級過程中發生的失敗事件日志。說明：該條款是對在線軟件升級場景（OTA場景）提出的要求；在線升級包在解包和分發之前，需要由車載軟件升級系統校驗其真實性和完整性，以保證在線升級包的真實來源和未受修改，其他環節是否進行校驗不在本文件中進行要求。離線軟件升級時，若車輛使用車載軟件升級系統進行離線升級，車輛應對離線升級包真實性和完整性進行校驗，若車輛不使用車載軟件升級系統進行離線升級，應采取保護措施保證刷寫接入端的安全性，或者校驗離線升級包的真實性和完整性。說明：若車輛不使用車載軟件升級系統進行離線升級，主要有以下兩類升級方式：a）使用診斷儀等基于OBD端口的設備進行刷寫升級；b）使用USB端口進行直刷（不經過車載軟件升級系統）。如果采用a）方式，要求車端刷寫準入端采用如27服務等防護措施對診斷儀等設備進行認證之后，才能進行刷寫操作；如果采用b）方式，要求ECU在被刷寫之前對離線升級包的真實性和完整性進行校驗。第10章數據代碼安全要求基于國內行業技術發展現狀，參考R155法規附錄5中的部分相關內容（表A14.3.6有關脆弱性/威脅的描述、漏洞及攻擊方法示例，以及表B5、B7、C3中有關的緩解措施），針對以下方面提出要求：車輛應安全的地存儲對稱密鑰和私鑰，防止其被非授權訪問和獲取。說明：常見的安全的存儲方式包括存儲在HSM、SE、TEE等安全模塊，也包括安全的軟件存儲形式。車輛應采取安全防御機制保護存儲在車內的車輛識別代號（VIN）和用于身份識別的數據，防止其被非授權刪除和修改。說明：此條要求中用于身份識別的數據由企業自行確定，包括直接用于身份識別的數據和組合起來間接識別身份的數據。車輛應采取安全防御機制保護存儲在車內的關鍵數據，防止其被非授權刪除和修改。說明：關鍵數據由企業根據車型的業務場景和風險評估來確認。車輛應具備個人信息清除功能及防恢復機制，便于在轉售、租借或報廢時清除個人信息。說明：國家要求存儲在車內不允許修改的數據除外，例如DSSAD、EDR內存儲的數據，防恢復機制在本標準中不提出強度要求，未來以數據安全標準要求的強度為準。車輛不得直接向境外傳輸數據。說明：此條款主要是避免車型設計時預留了數據出境的功能或接口，導致大批量的車輛避開管理部門的監管向境外直傳數據。車輛通過國內云平臺中轉間接向境外傳遞數據，用戶個人行為的跨境數據傳輸均不受本條款的要求。附錄A（規范性）車輛信息安全要求測試驗證方法對測試條件、測試輸入信息、車輛外部連接安全測試方法、車輛通信通道安全測試方法、車輛軟件升級安全測試方法、車輛數據代碼安全測試方法等內容進行了規定，并分別與正文第7章~第10章的要求條款進行對應，給出具體的通過條件。（五）主要試驗（或）驗證情況分析根據工作安排，中國汽車技術研究中心有限公司、工業和信息化部計算機與微電子發展研究中心（中國軟件評測中心）、上海機動車檢測認證技術研究中心有限公司、中國汽車工程研究院股份有限公司、招商局檢測車輛技術研究院有限公司、襄陽達安汽車檢測中心有限公司等6家檢測機構以及上海汽車集團股份有限公司、重慶長安汽車股份有限公司、廣州汽車集團股份有限公司、吉利汽車研究院（寧波）有限公司、東風汽車集團有限公司、上海蔚來汽車有限公司、廣州小鵬汽車科技有限公司、北京車和家汽車科技有限公司、梅賽德斯-奔馳集團股份公司、寶馬（中國）服務有限公司、一汽-大眾汽車有限公司、一汽解放汽車有限公司等進行了汽車信息安全管理體系審核、車輛技術要求的試驗方法驗證，以下選擇有代表性的驗證內容對驗證主要情況進行說明。汽車信息安全管理體系審核評估結果在審核期間，汽車生產企業依據秘書處發出的《體系審核表》進行材料準備，采取文件展示、現場演示等方式，通過現場/遠程方式進行審核，評估企業是否滿足本標準草案中的要求。經審核發現，所有參與驗證活動的整車生產企業均建立汽車信息安全管理體系框架，初步形成面向汽車產品的信息安全管理制度，能夠覆蓋本標準第5章的條款要求，但不同企業的落地執行方式不同、所執行顆粒度有所差異。為便于行業理解以及加強企業落地可操作性，特作如下說明：（1）車輛制造商應建立車輛全生命周期的信息安全管理體系。說明：ISO21434《道路車輛信息安全工程》可作為證明和評估信息安全管理體系所需階段的依據。第9章“概念階段”、第10章“產品開發”和第11章“信息安全驗證”可用于評估信息安全管理體系的開發階段。第12章“生產”可用于評估信息安全管理體系的生產階段。第7章“持續的信息安全活動”、第13章“操作和維護”以及第14章“報廢”可用于評估信息安全管理體系的后生產階段；（2）應建立企業內部管理信息安全的流程。說明：本條款中提及的企業內部管理信息安全的流程，指在組織層級與車輛信息安全強相關的流程，對于組織本身的信息安全流程，如：針對企業IT系統的信息安全管理流程等不在本標準考慮范圍內。此外，本條款可參考ISO21434《道路車輛信息安全工程》中第五章“組織信息安全管理”中的要求，從治理文化、信息共享、安全審核、工具管理、持續改進等方面進行開展。（3）應建立識別、評估、分類、處置車輛信息安全風險及核實已識別風險得到適當處置的流程，并確保車輛風險評估保持最新狀態。說明：本條款中提及的風險指車輛全生命周期中的信息安全風險，覆蓋研發階段、生產階段、后生產階段。企業根據實際需求與業務場景，定義車輛全生命周期中的信息安全風險管控流程。此外，ISO21434《道路車輛信息安全工程》中第十五章提及的威脅分析與風險評估方法論可供參考，企業可自行選擇是否采用。（4）應建立針對車輛的網絡攻擊、網絡威脅和漏洞的監測和響應流程，要求如下：a）應包含確保已識別的網絡威脅和漏洞得到響應，且在合理的時限內得到處置的流程；說明：本條款中提及的“合理時限”當前可由企業結合實際情況自行定義，“處置”包括采取緩解措施、修復、持續監測等方式。此外，此次審核發現：針對于合資企業和外資企業，其部分體系文檔（尤其是車輛產品開發相關制度）保存在國外，且供應商來自于各個國家，在審核時存在無法提供資料或提供的資料難以審查（非中英版本）的情況，需在標準中進行明確約束。車輛信息安全一般要求評估結果經審核評估發現，汽車生產企業針對部分新車型已開展信息安全活動，但由于車型項目尚處于概念階段，無法依據所建立的汽車信息安全管理體系開展全部活動。且部分企業執行的信息安全活動與建立的流程規定并不一致?？紤]到目前汽車生產企業的信息安全管理體系亦正處于建設過程中，需預留充足時間供其新款車型研發驗證。同時，在審核時發現，對于風險評估活動而言，企業開展形式不一；對于供應商管理而言，汽車企業能夠提出明確的信息安全技術要求，但針對于職責劃分、工作內容等，企業開展形式不一等等?？傮w來說，被審核的汽車生產企業對于本標準的第六章條款要求理解無明顯偏差。此外，由于合資企業屬性，車輛產品由國內外團隊共同完成，但國外團隊并不會向國內團隊提供完整的風險評估和相關處置文檔，因此，存在車型產品開發完成后，但實際風險評估不充分的可能性，車型產品的安全性存在較大風險。車型技術要求試驗結果測試開始前，需結合車輛信息安全一般要求的評估結果確認適用于該車型的測試項，并獲取必要的測試輸入信息。測試輸入信息并不一定需要提供完整的文本材料，車輛生產企業針對不同的測試輸入信息可以采用不同的方式提供測試輸入，不同的測試輸入信息提供方式如下：（1）測試人員和車輛生產企業技術人員通過會議溝通確認：測試車輛遠程控制功能，包括遠程控制指令應用場景和使用權限；測試車輛授權第三方應用真實性和完整性驗證方式；測試車輛非授權第三方應用的訪問控制機制；測試車輛外部接口；與測試車輛通信的車輛生產企業云平臺；測試車輛通信方法，包括采用的通信協議類型；測試車輛V2X功能；測試車輛向外傳輸敏感個人信息的通信通道；測試車輛與外部直接通信零部件；測試車輛個人信息清除功能及防恢復機制。（2）車輛生產企業技術人員先提供目錄清單，然后測試人員在車輛生產企業現場確認測試必須的詳細信息：遠程控制指令審計方式及審計日志記錄地址、車輛記錄異常指令的地址；測試車內通信方案及通信矩陣樣例，包括專用數據通信矩陣樣例；測試車輛對稱密鑰和私鑰的存儲方式及說明文檔；測試車輛內部存儲敏感個人信息存儲地址；測試車輛內存儲的車輛識別代號和用于身份識別的數據清單及存儲地址；測試車輛內存儲的關鍵數據清單及存儲的地址。（3）車輛生產企業安排技術人員攜帶相應的工具在檢測機構現場協助完成測試，測試結束后工具收回：測試車輛車載軟件升級系統可信根、引導加載程序、系統固件的訪問方式和地址；測試車輛實現離線軟件升級的方式及工具。按照2021年10月項目組第6次會議形成的文件開展了驗證測試，不同車輛測試項目并不完全相同（全覆蓋為80項測試項），下表中給出了標準驗證的總體情況。序號標準條款通過情況不可行/未通過試驗主要原因1外部連接安全要求對應15項測試項通過數量：11不通過數量：2未試驗數量：2完成13項測試項的驗證，剩余2項測試項被GB34660-2017覆蓋未開展驗證試驗；13項測試項中有11項測試方法得到認可，2項測試方法需進行調整。2通信安全要求對應40項測試項通過數量：25不通過數量：8未試驗數量：7完成33項測試項的驗證，剩余7項與V2X相關，由于本次送檢車型均不具備V2X功能，未開展驗證試驗；33項中有25項測試方法得到了認可，8項測試方法需要進行調整。3軟件升級安全要求對應13項測試項通過數量：7不通過數量：6未試驗數量：0完成了全部測試項的驗證；13項測試項中有7項方法得到了認可，6項測試方法需進行調整。4數據代碼安全要求對應12項測試項通過數量：11不通過數量：1未試驗數量：0完成了全部測試項的驗證；12項測試項中有11項方法得到了認可，1項測試方法需進行調整。測試驗證情況總體總結及重點問題說明：（1）車型流程審核是開展車型技術要求試驗驗證的基礎，車型技術要求試驗驗證是對車型流程審核結果的補充確認。（2）測試驗證時發現測試項可能無法完全覆蓋技術要求，若企業風險評估后的緩解措施多于技術要求，多出來的企業自定義安全措施需進行評估確認，不再進行測試。（3）部分測試方法可能會影響企業平臺運行。示例：標準原文-8.1.1.1車輛與車輛、路邊單元、服務平臺等的通信，應實施身份認證。測試項-A.5.1.1.1.1與服務平臺通信的身份認證試驗方法：a)若車輛與服務平臺通信采用公有通信協議，采用網絡數據抓包工具進行數據抓包，解析通信報文數據，檢查是否采用如TLSV1.2同等安全級別或以上要求的安全通信層協議；b)若車輛與服務平臺通信采用私有通信協議，對私有通信協議方案進行審核，采用網絡數據抓包的方法進行數據抓包，解析通信報文數據中加密密鑰衍生、更新及存儲策略，檢查是否支持以安全方式進行定期更新，并以安全的方式存儲加密密鑰。c)依據車輛端通信部件清單，使用車輛端設備和服務平臺的合法證書，檢測雙方是否能夠完成身份認證以進行后續通信；d)分別替換偽造的車輛端設備和服務平臺的證書，測試是否能夠通過身份認證并進行后續通信。說明：送檢車輛連接的平臺均為實際生產平臺，進行證書替換，采用私有APN通訊的認證方式可能影響已售車輛運行。（4）部分企業產品采取的防護技術可能會影響測試項執行，將通過審核的方式補充證明。示例：測試項-A.5.4.1車輛傳輸的機密數據保密性試驗/防止敏感信息泄露試驗。測試人員應依據車輛傳輸機密數據清單，按照如下方法，檢驗測試車輛是否滿足正文8.4.1的要求：a)抓取通訊數據包，檢查是否正確使用聲明的加密算法對車輛傳輸的機密數據進行加密；b)檢查使用的加密算法強度是否滿足需求。說明：標準技術要求“8.1.1.1車輛與車輛、路側單元、服務平臺等的通信，應實施身份認證”，企業為滿足此條款要求，采用了TLS1.2以上安全通訊協議時，測試人員無法通過技術測試驗證的方式核查此時傳輸的數據消息體本身是否依照聲明的算法進行數據加密；（5）通過本次標準驗證試驗，對部分測試方法進行優化調整：a)若基于第7-10章安全技術要求的風險處置措施與企業所識別的風險不相關，無需對不相關的條款開展測試，僅需開展評估確認。b)若基于第7-10章安全技術要求的風險處置措施無法覆蓋企業所識別的風險，應在按照附錄A開展測試驗證的基礎上，對企業實際所使用的處置措施開展評估確認。c)若基于第7-10章安全技術要求的風險處置措施適用于企業所識別的風險，按照附錄A.4-A.7的要求開展驗證，其中適用于現場測試的條款依照文件中列出的條款開展測試進行確認，不適用于現場測試的條款通過審核研發階段的第三方測試報告進行確認。試驗驗證流程總結三、與有關法律、行政法規和其他標準的關系本標準是我國智能網聯汽車管理的重要內容；與現行相關法律、法規、規章及相關標準沒有沖突或矛盾。四、與國際標準化組織、其他國家或者地區有關法律法規和標準的比對分析本標準未采用國際標準，基于國內行業發展現狀和管理需求自主制定。202