车联网安全标准：IEEE 1609.2a-2017修订版

1609.2

需积分: 9 187 浏览量更新于2024-07-16 1 收藏 3.02MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"IEEE_Std_1609_2a-2017.pdf是关于车联网规范的2017年修订版，主要关注证书和安全服务，适用于V2X（Vehicle-to-Everything）通信。该标准由IEEE智能交通系统委员会的IEEE车载技术学会赞助。" **车联网规范IEEE 1609.2简介** IEEE 1609.2是无线接入车载环境（Wireless Access in Vehicular Environments, WAVE）的安全服务标准，其目的是确保车辆间通信（V2X）的安全性。这个标准在2016年的基础上进行了修订，加入了Amendment 1，进一步提升了安全性。 **主要内容** 1. **安全消息格式和处理**：定义了用于WAVE设备的加密消息格式和处理方法，这些方法涵盖了对WAVE管理消息的保护，以及对应用消息的保护。这包括消息认证、加密和完整性保护，以防止数据篡改和中间人攻击。 2. **核心安全功能的支持**：描述了支持这些安全服务所必需的管理功能，如密钥管理和证书分发，这对于保持网络中的身份验证和数据保密性至关重要。 3. **密码学应用**：标准中使用了密码学技术，包括公钥基础设施（PKI）和数字证书，以建立和验证通信双方的身份，确保消息的机密性和完整性。 4. **关键词**：除了IEEE 1609.2之外，还提到了“cryptography”（密码学），强调了密码学在实现这些安全服务中的关键作用。 5. **WAVE管理消息和应用消息的保护**：针对WAVE系统中的管理消息（如网络配置和状态更新）和应用消息（如交通警告或交通信息），提供了特定的安全机制，以确保信息的正确传输和接收。 6. **智能交通系统**：作为IEEE智能交通系统委员会的工作成果，此标准旨在提升道路安全和交通效率，通过V2X通信支持自动驾驶和协同驾驶。 **应用场景** - **碰撞预防**：通过实时共享位置和速度信息，车辆可以预测潜在的危险情况，提前做出反应。 - **交通流优化**：车辆可以共享交通拥堵、事故或其他道路条件信息，帮助驾驶员规划路线，减少拥堵。 - **紧急服务通信**：紧急车辆可以广播其位置和优先级，其他车辆可以自动让路。 - **公共服务**：提供天气警报、停车信息等公共信息，提升驾驶体验。 IEEE Std 1609.2a-2017为车载无线通信设定了严格的安全标准，是实现安全、可靠的V2X通信的基础，对于推动智能交通系统的发展具有重要意义。

资源详情

资源推荐

IEEE Std 1609.2a-2017

IEEE Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management

Messages—Amendment 1

Conformance Statement (PICS) proforma given in Annex A allows the vendor of an implementation of

WAVE Security Services to state the maximum length of certificate chain that the implementation

supports.

5.1.2.3 Cryptographic validity of a chain

Change the captions of Figure 5 and Figure 6 as follows:

Signed Data

signer

Issuer’s signature

End-Entity Certificate

issuer identifier

public key

Issuer’s signature

Root CA Certificate

public key

Issuer’s signature

verifies

issuer ↑ ↓ subordinate

↓ trust anchor

identifies

Figure 5—Cryptographic verification withof a signed SPDU and

with a full certificate chain,

using explicit certificates

Signed Data

signer

Issuer’s signature

End-Entity Implicit

Certificate

issuer identifier

CA Implicit Certificate

signer_id

reconstruction

value

combine to verify

CA Certificate

issuer identifier

public key

Issuer’s signature

issuer ↑ ↓ subordinate

↓ trust anchor

identifies

reconstruction

value

Figure 6—Cryptographic verification of a signed SPDU and

with a (non-full) certificate

chain with implicit certificates

and a non-root CA as trust anchorend-entity certificate

IEEE Std 1609.2a-2017

IEEE Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management

Messages—Amendment 1

5.1.2.4 Consistency of permissions within a certificate chain

Change the indicated text in 5.1.2.4 as follows:

A self-signed certificate (i.e., a root CA certificate) is consistent with itself by definition. A subordinate

certificate is consistent with its issuing certificate if the following conditions hold:

 Consistency of application/issuance permissions: The subordinate certificate’s application or

certificate issuance permissions are consistent with the issuing certificate’s certificate issuance

permissions, i.e., for every (PSID, SSP) entry in the subordinate certificate’s application or

certificate issuance permissions (the “subordinate entry”) there is an entry in the issuing

certificate’s certificate issuance permissions (the “issuing entry”) such that:

 [other bullet points omitted]

 If the subordinate entry is for certificate issuance or request permissions

, the permitted

depthlength of the chain in the subordinate entry is consistent with the permitted depthlength

of the chain in the issuing entry. Specifically, if minChainDepthminChainLength and

chainDepthRangechainLengthRange in the subordinate certificate and issuing certificates

have the values mcdmcr

, cdrclr

, mcdmcr

, cdrclr

, respectively, then mcdmcr

≤ mcdmcr

and (mcdmcr

+ cdrclr

) ≥ (mcdmcr

+ cdrclr

+1). (In the case where the subordinate

certificate is an end-entity certificate, mcdmcr

and cdrclr

are set equal to zero (0) in these

formulas.)

Insert 5.1.2.4a after 5.1.2.4:

5.1.2.4a Trustworthiness of a certificate chain

A certificate chain is trustworthy if the following hold:

 Each subordinate certificate is consistent with its issuing certificate.

 The chain begins with a trust anchor.

 None of the certificates in the chain have been revoked, as discussed in 5.1.3.

 (Optional) none of the certificates in the chain have expired at the time of chain verification,

as discussed in 5.2.4.2.1 and 5.2.4.2.7.

Whether the expiry test is applied is specified as part of the SDEE specification, as discussed in 5.2.4.2.7. It

is strongly recommended that chains with expired certificates are treated as untrustworthy.

5.1.3 Revocation and expiry

5.1.3.1 General

Change the first four paragraphs of 5.1.3.1 as follows:

A certificate is said to be revoked if an appropriately authorized entity states that that certificate is known

not to be trustworthy. If a certificate is revoked, the SDS shall consider all SPDUs signed by that certificate

and received after the issue date of the revocation statement to be invalid even if their stated generation

time is before the issue date of the revocation statement.

If a CA certificate is revoked, the SSME shall indicate that any certificates issued by that CA certificate and

first received after the issue date of the revocation statement are revoked, even if their stated generation

IEEE Std 1609.2a-2017

IEEE Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management

Messages—Amendment 1

timestart of validity period is before the issue date of the revocation statement. This applies to any

certificate that chains back to the revoked CA certificate.

Information about revoked certificates is stored by the SSME via the 9.4.9.1 SSME-AddRevocation-

Info.request and 9.4.9.6 SSME-AddRevocationInfo.confirm primitives. The SSME provides the revocation

status of certificates via the 9.4.1.1 SSME-CertificateInfo.request and 9.4.1.6 SSME-Certificate-

Info.confirm primitives. Revocation information consists of a series of individual data items and

information allowing the SSME to associate the revocation information with specific certificates.

For any certificate C, there is at most one authority with authorization to issue revocation information for

that certificate. Each such authority might be entitled to issue and keep up to date more than one set of

revocation information R, but there is one specific set that is identified as the one that will indicate that

contain revocation information about C if it is revoked. If R does not indicate that C is revoked, then C is

not revoked.

Within the SSMETherefore, the process of determining whether or not a certificate is revoked involves two

steps:

a) Determine which set of revocation information applies to the certificate.

b) Determine whether any individual data item within the relevant revocation information indicates

that the certificate is revoked.

5.1.3.2 Determining which revocation information applies to a given certificate

Change the start of 5.1.3.2 as follows:

Revocation information applies to a given certificate if it:

 Indicates the same

that certificate’s Certificate Revocation Authorizing CA (CRACA) certificate,

and

 Indicates the same that certificate’s CRL Series value, and

 Is of the appropriate type (linkage-based or hash ID-based)

The

A CRACA is a CA that has authority to authorize the issuance of revocation information for a

particular group of other certificates. The CRACA certificate for a certificate C is only valid if it is onone

of the certificates in C’s issuingfull chain. Likewise, when the revocation information is transported in the

form of a signed CRL, the CRACA certificate is only valid if it either signed the CRL itself, or issued the

certificate that signed the CRL.

5.1.3.3 Identification of CRACA certificate

Change the text of 5.1.3.3 as follows:

A certificate contains a cracaId field as specified in 6.4.8. This is an octet string of length 3. The relevant

CRACA certificate is the certificate in the full chain for which the low-order three bytes of its SHA-256

hash are equal to the cracaId. The hash of the certificate is obtained as specified in 6.4.3.

A cracaId of all 0s and a CrlSeries value of 0 indicates that the certificate will not be revoked, i.e., that

there is no revocation list that it will appear on. This may be because it

the certificate has a very short

lifetime or for some other reason.

IEEE Std 1609.2a-2017

IEEE Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management

Messages—Amendment 1

A cracaId of all 0s and a non-zero CrlSeries value indicates that the certificate will appear on a CRL signed

by itself.

If a certificate has a non-zero cracaId, and the cracaId is not matched by a unique certificate in the full

chain (i.e., either it is not matched at all, or it is matched by more than one certificate), then the number of

certificates in the chain that match the cracaId is anything other than 1, the certificate is invalid.

5.1.3.6 Dubious certificates

Change the text of 5.1.3.6 as follows:

For each known (CRACA, CRL Series) pair, the SSME maintains an expected update time, i.e., the time

when the revocation information issuer has indicated that revocation information is going to be updated.

This value is set to “undefined” if the SSME has never received revocation information for that (CRACA,

CRL Series) pair. The expected update time for revocation information contained in a CRL is given in the

nextCrl field.

A certificate is considered by the SSME to be a dubious certificate if either no revocation information is

available for that certificate, or the expected update time for that revocation information is in the past.

If queried about the revocation status of a dubious certificate via SSME-CertificateInfo.request, the SSME

indicates that the certificate is dubious via SSME-CertificateInfo.confirm.

Any certificate in the full chain associated with a signed SPDU might potentially be dubious. The primitive

Sec-SecureDataPreprocessing.confirm indicates the earliest nextCrlTime time associated with any

certificate in the full chain associated with a signed SPDU. If that time is in the past, the certificate is

considered dubious.

The standard provides the following mechanisms to handle the case where the SDS determines that a

SPDU signed with a dubious certificate would be valid if the certificate was known not to be revoked, i.e.,

it passes all checks except that its revocation status is undetermined:

 Use Overdue CRL Tolerance within SDS: The SDS may be passed a parameter Overdue CRL

Tolerance via Sec-SignedDataVerification.request. In this case, if the earliest nextCrl

time for

any certificate in the full chain is in the past by more than Overdue CRL Tolerance, the SDS

indicates that the signed SPDU is invalid. If the parameter is not passed, the SDS indicate as valid a

signed SPDU that meets all other validity conditions, regardless of the

nextCrl time values.

 SDEE-specific processing: The SDEE may alternatively obtain the earliest nextCrl

time for any

certificate in the full chain via Sec-SecureDataPreprocessing.request, Sec-SecureDataPre-

processing.confirm. How a SDEE handles dubious certificates is SDEE-specific.

5.2 Signed SPDU validity

5.2.1 General

Change the text of 5.2.1 as follows, and insert the indicated figures:

A signed SPDU for a SDEE is valid for use by a receiving SDEE if all of the following hold:

剩余122页未读，继续阅读

dwqqwdpl2008

粉丝: 0
资源: 7

车联网安全标准：IEEE 1609.2a-2017修订版

【最新版】 IEEE Std 2030.7-2017.pdf

IEEE_Std1800-2017---_SystemVerilog2017_IEEE1800-2017_IEEE1800_

芯片研究：2022年春季的张X-M. Yung和M.-H.s的芯片1，2（DOI：10.1016/j.chip.2021.100002）

销售大数据中分布式环境下的关联规则挖掘与一致性检测的研究及比较 - 2017年SCI文章.

基于去噪策略的OFDM信道估计技术的综述 - 2017年国际期刊629页完整文章

球面机构多自由度各向同性分析的瞬时极点方法及其有效性-2017国际期刊

ieee.numeric_std.all 都有什么函数？

Type error resolving infix expression "mod" as type ieee.std_logic_1164.STD_LOGIC_VECTOR.

bin_num <= std_logic_vector(to_unsigned(to_integer(numeric_std.unsigned(hex_num)), 16));为何以上代码出现如下错误Error (10482): VHDL error at num_display.vhd(42): object "numeric_std" is used but not declared

ieee std 1003.1-2017

ieee std 802.15.8 -2017

ieee.numeric_std.all integer转STD_LOGIC_VECTOR

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL entity display is port( clock: in std_logic; reset: in std_logic; input: in std_logic_vector(3 downto 0); output: out std_logic_vector(7 downto 0) ); end display;检验这个代码的正确性

最新资源