AUTOSAR 安全硬件扩展规范 R22-11

需积分: 0 88 浏览量更新于2024-06-14 收藏 1.26MB PDF 举报

"该文档是AUTOSAR(Automotive Open System Architecture)组织发布的‘Specification of Secure Hardware Extensions’，属于AUTOSAR标准的基础部分，针对R22-11版本。文档详细阐述了安全硬件扩展的规范，旨在保护车载电子系统的知识产权，并要求商业利用必须获得相关知识产权许可。此文档自R19-11版本开始发布，经过多次更新但内容无变化，至R22-11版本稳定。" 在汽车行业中，AUTOSAR是一种开放的系统架构，它定义了一套标准化的方法和技术，用于开发复杂的汽车软件系统。此文档《Specification of Secure Hardware Extensions》主要关注的是如何在AUTOSAR框架下实现安全的硬件扩展，以确保汽车电子控制单元（ECU）的安全性和数据完整性。安全硬件扩展是现代汽车中至关重要的组成部分，因为它们能够防止未经授权的访问、篡改和攻击。这些扩展可能包括加密硬件模块、安全微控制器、安全接口以及相关的安全算法和协议。文档中可能会详细介绍以下关键知识点： 1. **安全设计原则**：涵盖设计安全硬件时应遵循的基本原则，如最小权限原则、安全隔离、安全认证和授权机制等。 2. **安全功能**：详细说明各种安全功能，如数据加密、硬件防火墙、安全启动过程、固件更新的安全验证等。 3. **硬件安全模块**：介绍用于实现安全功能的硬件组件，如加密协处理器、安全存储器和物理不可克隆函数（PUF）等。 4. **安全通信**：描述如何通过安全通道进行ECU之间的通信，防止中间人攻击和数据篡改。 5. **安全生命周期管理**：讨论从开发到退役的安全流程，包括固件更新、漏洞管理和退役策略。 6. **安全评估与认证**：阐述如何对硬件扩展进行安全评估，以满足行业标准（如ISO 26262、SPICE等）和法规要求。 7. **知识产权保护**：由于文档指出其内容受到版权和其他知识产权的保护，因此可能包含关于如何合法和合规地使用这些技术的信息。 8. **兼容性与互操作性**：确保安全硬件扩展能够与其他AUTOSAR组件无缝集成，保证整个汽车软件系统的兼容性和互操作性。 9. **案例研究与应用示例**：可能提供实际应用案例，帮助读者理解如何在实际项目中实施这些安全措施。《Specification of Secure Hardware Extensions》是面向汽车软件工程师和系统设计师的重要参考资料，它提供了在AUTOSAR环境中构建安全硬件扩展的全面指南，有助于提升汽车网络安全水平。

Specification of Secure Hardware Extensions

AUTOSAR FO R22-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 R22-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页未读，继续阅读

希瓜

粉丝: 0
资源: 2

AUTOSAR 安全硬件扩展规范 R22-11

这个是软件工程的论文 ,各方面的资料

Specification by Example - How Successful Teams Deliver the Right Software

Java 9 Data Structures and Algorithms

【Database Connection Pool】: The Secret to Efficient Connection Management with Python and MySQL

Monitoring MySQL Database Performance with Python: Essential Tools and Professional Techniques

VirtualBox Virtual Machine Migration to the Cloud: Cloud Computing Applications

C#ASP.NET网络进销存管理系统源码数据库 SQL2008源码类型 WebForm

(源码)基于ZooKeeper的分布式服务管理系统.zip

23python3项目.zip

技术资料分享AL422B很好的技术资料.zip

最新资源