硬件安全标准J3101：保障联网与自动驾驶汽车的安全基础

SAE-2020-J3101

5星 · 超过95%的资源需积分: 50 74 浏览量更新于2024-07-15 1 收藏 1.78MB PDF 举报

"SAE-2020-J3101-硬件安全标准.pdf" 是美国汽车工程学会(SAE)于2016年发布的一份关于车辆硬件安全的重要标准文档，旨在为汽车行业提供硬件安全机制的综合指南，以及最佳实践。这份标准重点关注设备身份验证、密封性、证明、数据完整性及可用性等方面，以确保车载计算机系统的可信度，并抵抗仅靠软件安全措施无法防范的各种攻击。在现代汽车行业，尤其是连接性和高度或全自动驾驶车辆中，硬件根信任和基于硬件的安全原语是必不可少的。该文档旨在为汽车供应链中涉及硬件安全功能的不同部分的工程师提供一个共同的参考，促进他们之间的沟通。硅片供应商可以通过此文档理解硬件安全基础及其应用，以满足车辆安全需求。同时，它有助于规范硬件安全特性，确保产品根据最终应用场景开发，并具备适当的安全级别。对于电子控制单元(ECU)供应商和系统集成商来说，文档中列出的不同安全需求和用例有助于他们评估系统面临的威胁，以及选择合适的硬件系统来应对这些威胁。文档内容包括介绍、范围和目标、参考文献等多个部分，详细阐述了硬件保护的安全措施及其在地面车辆中的应用。 1.1 范围和目标：该文档的目标是提供一套全面的安全机制，适用于汽车环境中的硬件，帮助工程师理解如何有效地使用这些机制。其范围涵盖了建立信任的多个方面，如设备身份、数据保护以及在面临各种潜在攻击时的系统韧性。 1.2 应用背景：随着车辆技术的不断发展，特别是联网和自动化程度的提高，硬件安全的重要性日益凸显。由于软件防护手段无法抵御所有类型的攻击，因此需要硬件层面的支持来增强系统的安全性。 2. 参考文献：文档引用了相关的行业标准和技术资料，为读者提供了更深入的理解和背景知识，帮助他们更好地实施和应用硬件安全策略。 SAE-2020-J3101 标准提供了车载硬件安全的全面框架，从基础概念到具体实践，指导行业参与者构建更为坚固的车载信息系统，确保车辆在面对复杂网络威胁时的安全性。无论是设计、制造还是集成汽车电子系统的工程师，都能从中受益，确保其产品符合日益严格的汽车安全标准。

SAE INTERNATIONAL

J3101

TM FEB2020

Page 13 of 80

6.1 Mandatory versus Optional and Required versus Conditional Presentation

Requirements

Section 7 will organize the common requirements into meaningful sets. The subsections presented as "required" are

necessary to appropriately characterize the common requirement addressed by the

subsection

们

tis

a necessary to achieve

the profile. Within each common requirement, "conditional" subsections may

implemented if appropriate

「

the

use case,

but may still be omitted

the profile

applied to a different use case. Statements within each section are marked

"mandatory" or "optional." If the implementation claims to meet the characteristics

the common requirement, the

"mandatory" statements must be supported.

subsections

common requirements marked

"required" may be omitted

if the profile does not include that common requirement, and "mandatory" statements within "conditional" subsections

common requirement are not necessary under appropriate use cases.

For example, the common requirements are presented using the following template headings:

Common Requirements

X.Y Heading

X.Y.Z Sub-Heading

X.Y.Z.1 Example Heading: Required

[MANDATORY] REQ_X.Y.Z.1_ 10: Requirement Text

[OPTIONAL] REQ_X.Y.Z.1_20: Requirement Text

X.Y.Z.2 Example Heading: Conditional

[MANDATORY] REQ_X.Y.Z.2_ 10: Requirement Text

[OPTIONAL] REQ_X.Y.Z.2_20: Requirement Text

NOTE: Some requirement numbers were associated with text which was deleted during development. The original numbers

requirements have been preserved for continuity and are not necessarily sequential.

6.2 Cryptographic Key Protection

2.1

Cryptographic Key Management Primer

A principal requirement

any hardware protected security environment is to provide a protected storage, management,

and usage

capab

小

for cryptographic keys. All mechanisms and functionality associated with managing crypto keys are

elements

secure cryptographic key management. Broadly, key management functionality encompasses the full lifecycle

of cryptographic keys, from genesis (i.e., generation, establishment, derivation, or input), storage, and management, to

destruction (zeroization). These key management facets may be described

terms of the hierarchy depicted

the following

figu

「

SAE INTERNATIONAL

Key

Agreement

J3101 TM FEB2020

Key Management

and

Provisioning

Symmetric

Aymmetric

Figure

2 -

Key

management

and

provisioning

Page 14

Hardware protected security environment key management functionality will encompass some

「

all

the key management

facets, depending on supported key types, cryptographic algorithms and protocols that are employed, and client functionality

demanded by larger system-level security services outside

the hardware protected security environment.

6.2.2 Cryptographic Key Protection Overview

A common requirement

any

hardwa

「

protected security environment

a protected storage and usage environment for

the purpose

storing cryptographic keys which

to be defined as a "keystore

Keystores: The component of the hardware protected security environment that directly manages the cryptographic keys

within a larger key management context is defined

a "keystore

The

keysto

飞

responsible for securely storing the keys

to prevent leakage or any unauthorized disclosure

keys outside of the hardware protected security environment.

Management and utilization

a keystore

a headline use case

the hardware protected security environment and

not

optional. While general purpose and embedded operating systems typically include APls to manage a "keystore

API

specifics are beyond the scope of SAE J3101 .

Hardware protected keystores are necessary to support persistent storage

all keys symmetric (secret) and asymmetric

(public and private key pairs).

Note that there is an overlap

function

the keystore with the core requirement of 6.5, and use cases

9.5, and

10.1

The keystore is fundamentally tied to the keys which enable cryptographic functions of the hardware protected security

environment. The keystore shall be specifically defined as distinct from more general nonvolatile data protection (within the

hardware protected security environment).

Secure key usage

another distinct aspect

the common requirements

the hardware protected security environment.

API is assumed to be required through which the normal environment and the secure environment can distinctly manage

and use the keystore without unauthorized disclosure

the keys

the keystore.

cryptography, secret and private keys

(symmetric and asymmetric) must be protected, but chosen algorithms are known.

Algorithms which use the key must maintain the security of the key during its use. Secure key storage and secure key usage

should be coupled. The exposure

the key can lead to the complete unravelling of the whole crypto scheme.

See 6.8.

SAE INTERNATIONAL

6.2.3 Requirements

6.2.3.1 Types

Keys

[MANDATORY] REQ_6.2.3.1_ 10:

[OPTIONAL] REQ_6.2.3.1_20:

6.2.3.2 Key Storage: Required

J3101 TM FEB2020

Page 15

The hardware protected security environment shall support digital certificates if

public keys (asymmetric cryptography) are employed. The digital certificates should

be X.509 or IEEE 1609.2 compatible formats.

The hardware protected security environment shall support either ephemeral or long-

term symmetric keys, or

both

This aspect

key management defines the rules and processes associated with secure persistent and/or ephemeral

storage

cryptographic keys. Proper key storage ensures protection

key material at rest.

[MANDATORY] REQ_6.2.3.2_ 10:

[MANDATORY] REQ_6.2.3.2_20:

[OPTIONAL] REQ_6.2.3.2_30:

A hardware protected security environment must securely store all cryptographic

keys and explicitly control access to each.

A keystore may be direct storage of the keys within the hardware protected security

environment, or use

external storage external to the hardware protected security

environment that

protected by encryption and integrity mechanisms implemented

within the hardware protected security environment.

Key storage capacities should only be constrained by the physical limits

the

underlying hardware. Allocation of storage between differing uses should

defined

under each application specified for the hardware protected security environment,

both

maximums and minimums. Denial

service due to exhaustion

available

resource should be mitigated by a resource manager implemented

either

hardware or firmware as a part

the hardware protected security environment.

NOTE: The hardware protected security environment

responsible for protecting both long-term and short-term

asymmetric and symmetric keys. Short term keys are sometimes referred

as ephemeral keys.

[MANDATORY] REQ_6.2.3.2_ 40: The hardware protected security environment keystore and its cryptographic key

contents shall be separately managed from any other nonvolatile data protection.

This includes other non-volatile data both within the hardware protected security

environment and in the normal environment.

[MANDATORY) REQ_6.2.3.2_50: The hardware protected security environment shall distinctly manage the

cryptographic integrity of the keystore from other components of the hardware

protected security environment.

[MANDATORY) REQ_6.2.3.2_60: The hardware protected security environment shall manage and maintain the

integrity of the entire keystore during any updates

the keystore

(add

巾

modification, or deletion

a key).

[MANDATORY) REQ_6.2.3.2_70: The hardware protected security environment shall check the integrity of the keystore

before any transaction which makes use of a stored key, as well as

response to

any conditions that warrant a check

the integrity of the keystore specified by the

system design (e.g

「

mal

or abnormal changes to power mode).

[MANDATORY] REQ_6.2.3.2_ 100: The hardware protected security environment keystore shall maintain the

identification and association

each cryptographic key to its authorized calling

application (called key-entity association), whether the application

located internal

or external to the

hardwa

「

protected security environment, and whether the key is

stored within or outside the protected hardware protected security environment

boundary.

SAE INTERNATIONAL

J3101

TM FEB2020

Page 16

[MANDATORY] REQ_6.2.3.2_ 110: The hardware protected security environment shall maintain the hierarchy and/or

association of all cryptographic keys within the keystore that are protected by other

stored cryptographic keys.

[MANDATORY] REQ_6.2.3.2_ 130: All cryptographic keys stored encrypted within the keystore (internal or external to

the hardware protected security environment secure boundary) shall be encrypted

by a cryptographic algorithm and key length combination that results

computational resistance to attack equal to or greater than the stored key.

[OPTONAL] REQ_6.2.3.2_ 140:

the encryption mode used to encrypt any internally or externally stored key requires

initialization vector, such shall be distinct in each key encryption operation.

[MANDATORY] REQ_6.2.3.2_ 150: The hardware protected security environment shall support binding

keys that are

stored encrypted within the keystore to a specific device.

NOTE: This prevents transferring encrypted keys stored in external non-volatile memories from a given device to prevent

copying the stored keys to multiple other devices.

6.2.3.2.1 Long-Term Keying Material Protection: Required

[MANDATORY] REQ_6.2.3.2.1_ 10: Long-term keys must be protected while at rest for confidentiality, integrity, and

against replay attacks. These attacks could be mounted

the nonvolati

storage

device containing these keys or

transit from the nonvolatile storage device to the

security module

the security module does not contain on-board nonvolatile

storage

6.2.3.2.2 Short-Term Keying Material Protecti

: Required

[MANDATORY] REQ_6.2.3.2.2_20: The hardware protected security environment shall protect the confidentiality and

integrity of short-term keys used

a session basis while

transit (during key

exchange operations) and against replay attacks.

[MANDATORY] REQ_6.2.3.2.2_30: The hardware protected security environment shall ensure that the exposure

any

short-term keys used

a session basis do not compromise the integrity and

confidentiality

any other short-term keys used

past or future sessions.

[OPTIONAL] REQ_6.2.3.2.2_ 10: The hardware protected security environment shall protect short-term keys used on

a session basis such that at the terminati

that session their use is also

terminated.

6.2.3.2.3 Symmetric Key Protected Storage: Required

[MANDATORY] REQ_6.2.3.2.3_ 10: Symmetric keys (also referred to as shared secret keys) shall be preserved for

integrity, confidentiality, and freshness.

[OPTIONAL] REQ_ 6.2.3.2.3_20: The hardware protected security environment shall encrypt internally stored

symmetric keys using

internally stored key encryption key.

[MANDATORY] REQ_ 6.2.3.2.3_

: The hardware protected security environment shall output externally stored

symmetric keys by a method that meets the key output requirements

this

document.

[OPTIONAL] REQ_6.2.3.2.3_50: The hardware protected security environment shall support a defined lifetime and a

means

rekeying for symmetric keys.

NOTE: There are multiple ways to ensure defined symmetric key lifetimes which are not necessarily date derived, such

usage

and/o

「

boot

cycle and/or ignition cycle counters. Hardware protected security environment enforcement

key lifetime

essential. Recommendations from various standards bodies

key lifetimes can be found at

htt~th

.com/en/4/.

剩余79页未读，继续阅读

challye

粉丝: 1
资源: 5

硬件安全标准J3101：保障联网与自动驾驶汽车的安全基础

SEA J1939 英文版

ISO-21434.pdf

sae j1939 几个主要文件（中文pdf版）

SAE J 1939-73.zip_1939_1939-73_J1939 73_J1939-73_sae-j1939-73

基于STM32的SAE-J1939协议在压裂车中的应用.pdf

SAE J3101：2020 Hardware Protected Security for Ground Vehicles - 完整英文电子版（80页）.pdf

基于STM32的SAE-J1939协议在压裂车中的应用.zip

sae_j2534-1_2004.pdf_J2534_J2534-1_saeJ2534_

SAE J2534-2-2019 Optional Pass-Thru Features - 完整英文版（140页）.pdf

SAE J1939-16 - 2018 Automatic Baud Rate Detection Process - 完整英文电子版（18页）.pdf

最新资源