汽车网络安全(信息安全)标准、规范
英文标题:Automotive Cybersecurity Standard and Specification
随着汽车互联化和智能化,汽车不再孤立,越来越多地融入到互联网中。在这同时,汽车也慢慢成为潜在的网络攻击目标,汽车的网络安全已成为汽车安全的基础,受到越来越多的关注和重视。如何实现汽车网络安全,汽车行业进行了很多探索,也取得了很多成果。为了降低成本和提高质量,将已有的成果规范化、标准化势在必行。本文就简要介绍汽车网络安全相关的标准和规范。
系统级规标
这里总结针对企业、组织、产品整个生命周期的规范、标准。
SAE J3061
Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
版本历史: 2016
SAE J3061是针对车辆整个生命周期的标准。提供了车辆网络安全的流程框架和指导,考虑了车辆的整个生命周期,从概念到生产、运行、维护和报废。
SAE J3061旨在帮助企业识别和评估网络安全威胁,导入网络安全到在车辆的整个开发流程内。SAE J3061主要内容为:
- 定义了完整的生命周期流程框架。企业可以裁剪、利用这个框架,将网络安全导入车辆的开发流程,包括概念到生产、运行、维护、报废
- 提供了指导原则
- 提供了车辆网络安全相关的工具和方法论
图片来自http://www.sae.org.cn/articles/14503 汽车互联网功能不断发展的同时,也使汽车成为潜在的攻击目标。
ISO 21434
Road Vehicle - Cybersecurity Engineering
标准进度:
- 2020/02 : DIS 版本发布
- 2021/05: FDIS 版本发布 (见 https://www.doc88.com/p-30259530707643.html)
- 2021/08: 标准正在批准中,即将发布
ISO 21434是基于SAE J3061制定的、针对车辆整个生命周期的标准。
基于SAE J3061,参考V字模型开发流程,讨论德国和美国SAE关于信息安全标准的立项建议,主要包括:信息安全相关的术语和定义;信息安全管理:包括企业组织层面和具体项目层面;威胁分析和风险评估(TARA);信息安全概念阶段开发;架构层面和系统层面的威胁减轻措施和安全设计;软硬件层面的信息安全开发,包括信息安全的设计、集成、验证和确认;信息安全系统性的测试及其确认方法;信息安全开发过程中的支持流程,包括需求管、可追溯性、变更管理和配置管理、监控和事件管理;信息安全事件在生产、运行、维护和报废阶段的预测、防止、探测、响应和恢复等。[7]
ISO 21434主要从风险评估管理、产品开发、运行/维护、流程审核等四个方面来保障汽车信息安全工程工作的开展。目标是通过该标准设计、生产、测试的产品具备一定信息安全防护能力。[7]
硬件级规标
信息安全硬件模块主要解决两个问题。
-
密钥泄漏问题。如果密钥存储在应用程序的代码或数据中,很容易被泄露,主要原因是
- 应用程序本身有权限读取密钥。应用程序本身逻辑漏洞可能导致密钥泄露。(windows操作系统有很多类似的漏洞)。
- 只能在应用程序上提供软件逻辑上的保护。因为应用程序的代码和数据一般机密性不高,所以硬件上对这一块没有太高的机密性保护。容易因为物理攻击导致密钥泄露。
解决办法就是增加一个硬件模块,专门存储密钥。
-
通用内核直接加密解密运算会占用内核大量资源。
解决办法就是增加一个硬件加速模块,运行加密解密运算。
所以硬件安全模块主要有两个功能
- 存储密钥
- 密码算法加速
SHE
Security Hardware Extension
版本历史: 2009
SHE是针对硬件模块的规范。汽车网络安全的实现不仅需要软件支持,还需要硬件的支持,所以奥迪和宝马合作制定了这个硬件密码模块规范,主要包括密码模块的硬件、硬件软件接口。这个规范已被广泛接受,很多针对汽车行业的微处理器都支持这个规范。
SHE是Secure Hardware Extension的缩写,汉语含义是“安全硬件扩展”。
SHE是一个对硬件的网络安全规范,它已经被广泛接受。
能找到的SHE规范名字,但是在网上下载不到原文: Secure Hardware Extension functional specification Version1.1 (rev4)
在 Autosar 官网可找到近似的文档: AUTOSAR_TR_SecureHardwareExtensions.pdf
Evita HSM
Evita是欧盟组织的一个项目,持续时间为2008至2011。其目标是研究网联汽车应用场景(V2X)下车辆的通信安全,基于SHE规范提出了HSM硬件规范。这个规范也被广泛接受,很多针对汽车行业的微处理器支持这个规范。
目标是研究V2X应用场景的网络安全。Evita项目的官网: evita 项目官网
在Evita的规范中,定义了HSM的功能。HSM是Hardware Security Module的缩写。
Evita把HSM分为三个等级,high、medium、light。Light版本的HSM近似SHE的功能。
三个等级的HSM的子部件:
(图片来自 EVITAD0 P5)
各种硬件模块的对比:
(图片来自 EVITAD3.2 P50)
下面是有带有high、mediem、light HSM 的传感器、控制器组成的安全网络实例。
SAE J3101
SAE J3101 Hardware Protected Security for Ground Vehicle
道路车辆某些网络安全保护措施基于硬件。这里的硬件指 HSM 这类硬件。SAE J3101 指定了针对这些硬件的需求。
SAE J3101 属于最佳实践类文档,关注整个网络安全体系中硬件的相关网络安全技术需求。
软件级规标
软件框架规范
Autosar
Autosar 是汽车行业公认的软件框架。
Autosar 也慢慢在其框架中引入信息安全相关的模块。截至 4.3.1 版本,已有
- Crypto Stack[9]
- Secure Onboard Communication[10]
在版本 4.4 中,针对信息安全会有以下改进[11]
- Security Event Memory
- Key Management / Key Distribution
- Authentic Synchronized Time
- Dynamic Rights Management for Diagnostic Access
- Improved Certificate Handling
软件代码规范
嵌入式系统常用的 C 语言是一种“不安全”的语言。C 语言的指针就是例子。指针很难理解(如果你学过 C语言应该会有同样感触),同时指针很容易导致各种问题(堆栈溢出、内存泄漏等)。
解决办法之一是规范代码的格式,不要使用比较容易出错的代码格式。
MISRA C
在MISRA C:2012 Amendment 1中,提供了针对信息安全的代码规范。
Additional security guidelines for MISRA C:2012 的下载地址
SEI CERT C Coding Standard
SEI CERT 定义了软件代码规范,目标是开发符合功能安全、信息安全和可靠的系统。
SEI CERT 相关网址:
- SEI CERTC Coding Standard 2016 的 下载地址
- https://wiki.sei.cmu.edu/confluence/display/c SEI的wiki
其他标准、规范
下面介绍的标准、规范和汽车行业不直接相关,但是很有影响力,值得了解一下。
NIST FIPS 140
National Institute of Standards and Technology Federal Information Processing Standards 140
FIPS 140标准适用于软件和硬件模块。
FIPS 140标准历史:
- 1994年,FIPS 140-1发布。
- 2001年,FIPS 140-2替代了FIPS 140-1。2019年,FIPS 140-3替代了FIPS 140-2。
- 最新版本的FIPS 140-3 基于 ISO/IEC 19790:2012(E) 和 ISO/IEC 24759:2017(E),做了一些调整。ISO 19790基于FIPS 140-3之前版本的网络安全需求,ISO24759基于FIPS 140-3之前版本的测试规范。
FIPS 140把网络安全等级分为4级,网络安全等级从低到高:
- 等级1:不考虑物理攻击,密码模块需要满足基本的网络完全要求(比如:密码模块至少使用一种被批准的算法或被批准的网络安全功能)。等级一的例子是电脑的加密功能。
- 等级2:在等级1的基础上增加了基本的防物理攻击的保护机制,需要显示被物理攻击的痕迹,比如只有破坏防拆封(tamper-evident)的涂层或密封条才能获取密码模块的密钥等。
- 等级3:在等级2的基础上加强防物理攻击的保护机制。等级3要求比较高概率低防止入侵者获取密码模块内的关键的网络安全相关的参数(比如密钥)。保护机制可能包括密码模块有很强的封装和物理攻击响应机制,当检测到物理攻击时会擦出内部的密钥等。
- 等级4: 最高的网络安全等级,物理机制必须提供全方位的保护,能够极高概率地检测到各种物理攻击。当检测到物理攻击时,需要删除内部的密钥等。等级4也要求密码模块不能因为外部环境环境(比如温度、电压)变化而被破解。 故障注入(fault injection)时通过控制外部环境来破解密码模块的一种方法。
如果想进一步了解故障注入攻击,可以参考Fault Injection on Diagnostic Protocols
参考
[1] NXP. Automotive Security - White Paper[EB/OL]. https://www.nxp.com/docs/en/white-paper/AUTOSECURITYWP.pdf, 2016-11-23.
[2] freescale. Using the Cryptographic Service
Engine (CSE) An introduction to the CSE module[EB/OL]. http://cache.freescale.com/files/32bit/doc/app_note/AN4234.pdf, 2016-3-9.
[3] NIST. NITS FIPS 140 -2 Security Requirements for Cryptographic Modules[EB/OL]. https://csrc.nist.gov/publications/detail/fips/140/2/final, 2001-5-25.
[4] NIST. NITS FIPS 140-3 Security Requirements for Cryptographic Modules[EB/OL]. https://csrc.nist.gov/publications/detail/fips/140/3/final, 2019-5-22.
[5] NIST. Cryptographic Standards and Guidelines[EB/OL]. https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines.
[6] BSI. Bundesamt für Sicherheit in der Informationstechnik. https://www.bsi.bund.de/EN/Home/home_node.html
[7] CESI. 汽车电子网络安全标准化白皮书(2018版). http://www.cesi.ac.cn/201804/3790.html, 2018-04-16.
[8] BSI. BSI Magazine - Security in focus. https://www.bsi.bund.de/EN/Publications/BSIMagazine/BSI-Magazine_node.html
[9] Autosar. Requirements on Crypto Stack[EB/OL]. https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SRS_CryptoStack.pdf, 2017-12-08.
[10] Autosar. Requirements on Secure Onboard Communication[EB/OL]. https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SRS_SecureOnboardCommunication.pdf, 2017-12-08.
[11] Vector. AUTOSAR 4.4 Security Enhancements[EB/OL]. https://assets.vector.com/cms/content/products/VectorCAST/Events/Symposiums/5_AUTOSAR_4.4_Security_Enhancements.pdf, 2018-10-30.
修订记录
2021-08-29
- 添加网络安全硬件相关最佳实践 SAE J3101
- 添加Autosar SHE 需求
2019-12
- 添加软件规范 MISRA-C, SEI CERT。并将相关标准简单分为系统、硬件和软件三大类。
- 添加 Autosar 的总结
2019-06-30
第一个版本。
版权声明: 本文为博主原创,未经许可,禁止转载。原为地址:https://www.cnblogs.com/byronsh/p/automotive-cybersecurity-standard-specification.html
本文会持续更新,如想查看最新内容,点击原文链接。