AUTOSAR 安全硬件扩展规范

版权申诉

5星 · 超过95%的资源 89 浏览量更新于2024-07-18 1 收藏 1.23MB PDF 举报

"AUTOSAR_TR_SecureHardwareExtensions.pdf 是一份关于AUTOSAR（AUTomotive Open System ARchitecture）安全硬件扩展规范的文档，主要针对智能驾驶和车辆标准领域。该文档由AUTOSAR组织发布，是R20-11版本的标准组件，旨在提供汽车软件架构的安全硬件扩展细节。文档在2020年11月30日进行了R20-11的更新，无内容变更；初次发布于2019年11-28，为R19-11版本。文档强调，其内容受版权和其他知识产权保护，商业利用需获得相应许可。" AUTOSAR（AUTomotive Open System ARchitecture）是一种全球性的汽车行业开放标准，用于定义汽车电子和软件系统的架构。它的目标是提高软件组件的可重用性、系统可扩展性和互操作性，从而降低开发成本并加速新功能的集成。这份"SpecificationofSecureHardwareExtensions"详细介绍了在AUTOSAR框架下实现安全硬件扩展的方法。安全硬件扩展是智能驾驶和车辆安全的关键部分，因为它们涉及确保车载系统的安全性和可靠性，防止恶意攻击和数据泄露。这些扩展可能包括： 1. 安全处理器：专为处理安全关键任务设计的微控制器，如加密、安全启动和安全通信。 2. 密钥管理：确保密钥的安全存储和传输，防止未经授权的访问和复制。 3. 安全边界：在硬件层面上建立安全隔离，防止一个组件的故障或攻击影响到其他组件。 4. 安全认证：实施身份验证机制，确保只有授权的软件组件才能运行。 5. 安全监控：监测系统行为，检测异常活动，及时发现潜在威胁。 6. 安全更新机制：提供安全的软件更新流程，防止在更新过程中引入新的安全漏洞。 7. 鲁棒的通信协议：采用加密和完整性检查机制，确保数据在车辆内外的传输安全。 8. 故障检测和恢复机制：当检测到系统故障或攻击时，能够快速响应并恢复到安全状态。通过这些硬件扩展，AUTOSAR标准旨在提升汽车电子系统的整体安全性，适应现代汽车对高级驾驶辅助系统（ADAS）和自动驾驶功能的需求。随着车辆变得更加互联和智能化，这些安全措施对于保障乘客安全和数据隐私至关重要。同时，文档也提醒读者，任何对文档中内容的使用都需要遵守AUTOSAR及其贡献公司的规定，尊重知识产权。

Specification of Secure Hardware Extensions

AUTOSAR FO R20-11

4.2 Basic Requirements

SHE has to be realized as an on-chip peripheral of the microcontroller. SHE must not

have any other connections except those explicitly specified within this document. If ad-

ditional resources have to be included to assure proper function during the fabrication

of the chip, all ports have to be physically and permanently deactivated if accessible

on external pins.

SHE can be connected to the CPU in several ways, e.g. through a dedicated interface

or an internal peripheral bus. The interconnection must be implemented in a way that

no other peripheral or an external entity can modify the data transferred between the

CPU and SHE.

SHE does not need to be fabricated in a special process to increase security nor need

any actions to be taken to strengthen the system against physical attacks, e.g. etching

the chip casing open, differential power analysis, glitching attacks.

Note: No sophisticated secure hardware mechanisms are required to meet the spec-

ification of SHE. However, a manufacturer may of course strengthen the design to

provide a higher secur ity level for higher security requirements.

SHE needs to be notified by a status signal whenever inter nal or external debuggers for

debugging software and hardware are attached and active. Examples for debuggers

are JTAG, BDM etc.

This document does only describe the technical parts of SHE. Processes and environ-

mental conditions, e.g. for inserting keys, are not subject of this specification.

12 of 67 Document ID 948: AUTOSAR_TR_SecureHardwareExtensions

Specification of Secure Hardware Extensions

AUTOSAR FO R20-11

4.3 Algorithms

All cryptographic operations of SHE are processed by an AES-128 [1]. The latency of

the AES must remain <2us per encryption/decryption of a single block, including the

key schedule.

Additionally, the performance of the AES must be high enough to allow for a secure

boot (see Chapter 4.10 for details) of 5% of the flash memory, but 32kByte at minimum

and 128kByte at maximum, of the microcontroller in <10ms.

In case the flash memory is slower than requested, the flash memory must be the

limiting factor for the secure boot and the limit has to be stated in the datasheet.

4.3.1 Encryption/decryption

For encryption and decryption of data, SHE has to support the electronic cipher book

mode (ECB) for processing single blocks of data and the cipher block chaining mode

(CBC) for processing larger amounts of data, see [2] for details.

The latency for both modes may not exceed the value given in the beginning of section

4.3

SHE can only process multiples of the block length of the AES, i.e. all necessary

padding has to be done by an application.

The input, output and key input as well as any intermediate results may not be directly

accessible by the CPU but access must be granted depending on the policies by the

controller logic of SHE.

4.3.2 MAC generation/verification

The MAC generation and ver ification has to be implemented as a CMAC using the AES-

128 as specified by [3]. See [4] for updated examples.

4.3.3 Compression function

The Miyaguchi-Preneel construction (see [5] Algorithm 9.43) with the AES as block

cipher is used as compression function within SHE. Messages have to be preprocessed

before feeding them to the compression algorithm, i.e. they have to be padded and

parsed into 128 bit chunks.

Padding is done by appending one ’1’ bit to the message M of bit-length l, followed by

k ’0’ bits, where k is the smallest, non-negative solution to the equation l + 1 + k ≡

88 mod 128. Finally append a 40 bit block that is equal to the number l expressed

using an unsigned binary representation.

13 of 67 Document ID 948: AUTOSAR_TR_SecureHardwareExtensions

剩余66页未读，继续阅读

电动汽车控制与安全

粉丝: 272
资源: 4186

AUTOSAR 安全硬件扩展规范

AUTOSAR入门篇 (2).pdf

[19]SHE Secure Hardware Extension.pdf

AUTOSAR软件架构_方法论_解决方案.pdf

AUTOSAR_TR_SecureHardwareExtensions.zip

AUTOSAR_TR_FoundationReleaseOverview.pdf

AUTOSAR_TR_BSWModuleList.pdf

AUTOSAR_TR_HWTestManagementIntegrationGuide.pdf

AUTOSAR_TR_SWCModelingGuide.pdf

AUTOSAR_TR_FunctionalClusterShortnames.pdf

AUTOSAR_TR_Glossary.pdf

最新资源