Document Purpose
Confirmed by requirements: this data security container / secure data transfer standard contributes 90 Markdown-derived RFQ requirements with the strongest evidence in secure communication and freshness protection.
CVS32
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
CVS32
Data Security Container / Secure Data Transfer Standard · Secure Data Transfer · Secure communication and freshness protection
Executive Takeaway
Confirmed by requirements: this data security container / secure data transfer standard contributes 90 Markdown-derived RFQ requirements with the strongest evidence in secure communication and freshness protection. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence.
Confirmed by requirements: supplier positioning is 4 accept; 43 accept with assumption; 39 partially accept; 4 informational only. The generated traceability links this document to 14 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Requirements90from this PDF
Critical39ranked
Open Points2linked
Derived SSRs14linked
Concept Impactyesdocument-specific
Estimation Impactyesdocument-specific
Document Abstract
Engineering Interpretation
Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence.
Main Requirement Themes
Secure communication and freshness protection; Core ECA system behavior; Cybersecurity concept and evidence; System architecture design; Responsibility and customer approval model (showing 5 of 8)
System / Security Impact
Inferred from mapped features, capabilities, and interfaces: the main design/security impact is secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Supplier Proposal Impact
Confirmed by requirements: supplier positioning is 4 accept; 43 accept with assumption; 39 partially accept; 4 informational only. The generated traceability links this document to 14 supplier system requirement records.
Customer Clarification Impact
Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. Do not convert these items into agreed baseline scope until the customer confirms the decision.
Confidence and Limits
Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Main Requirement Themes
| Theme | Engineering Meaning | Requirement Count | Representative Requirements |
|---|---|---|---|
| Secure communication and freshness protection | Defines protected communication behavior, freshness/replay checks, and signal or PDU allocation dependencies. | 82 | REQ-AUTO-00992; REQ-AUTO-00993; REQ-AUTO-00994 |
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 71 | REQ-AUTO-00987; REQ-AUTO-00988; REQ-AUTO-00989 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 47 | REQ-AUTO-00989; REQ-AUTO-00990; REQ-AUTO-00991 |
| System architecture design | Groups related document requirements into a single engineering theme. | 44 | REQ-AUTO-00987; REQ-AUTO-00988; REQ-AUTO-00993 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 33 | REQ-AUTO-00989; REQ-AUTO-00990; REQ-AUTO-00992 |
| System | Groups related document requirements into a single engineering theme. | 19 | REQ-AUTO-00987; REQ-AUTO-00988; REQ-AUTO-00993 |
| External interfaces | Groups related document requirements into a single engineering theme. | 18 | REQ-AUTO-00999; REQ-AUTO-01001; REQ-AUTO-01004 |
| Interface | Groups related document requirements into a single engineering theme. | 18 | REQ-AUTO-00999; REQ-AUTO-01001; REQ-AUTO-01004 |
Document Content Structure
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 1 Introduction | 1 | 0 | 0 | 1 |
| -- 1.3 Document Quirks | 1 | 0 | 0 | 1 |
| 2 General | 5 | 2 | 1 | 2 |
| 3 ISO 14299-1:2020 Clarifications and Deviations | 80 | 37 | 1 | 10 |
| -- 3.1 Anti-replay Protection and Transaction Coherency | 11 | 6 | 1 | 3 |
| -- 3.2 Authenticity and Confidentiality | 48 | 17 | 1 | 9 |
| -- -- 3.2.1 HKDF Key Derivation | 4 | 1 | 1 | 3 |
| -- -- 3.2.2 SDT_AEAD_CHACHA20_POLY1305 | 19 | 7 | 1 | 6 |
| -- -- -- 3.2.2.2 Server Decryption/Encryption | 12 | 5 | 1 | 4 |
| -- -- 3.2.3 SDT_POLY1305 | 16 | 6 | 1 | 8 |
| -- -- -- 3.2.3.2 Server Verification/Authentication | 11 | 4 | 1 | 5 |
| -- 3.3 Error- and state-handling | 21 | 14 | 1 | 4 |
| -- -- 3.3.1 Server’s Behaviour | 13 | 12 | 1 | 3 |
| -- -- -- 3.3.1.1 SDT transactions with multiple responses | 9 | 9 | 1 | 2 |
| -- -- 3.3.2 Client’s Behaviour | 8 | 2 | 1 | 3 |
| -- -- -- 3.3.2.1 Lost and Repeated SDT Messages | 5 | 2 | 1 | 2 |
What This PDF Is About
| Field | Value |
|---|---|
| Source PDF | customer-input/pdf/CVS32.pdf |
| Converted Markdown | converted/markdown/CVS32.md |
| Document Type | Data Security Container / Secure Data Transfer Standard |
| Domain | Secure Data Transfer |
| Scope Summary | 90 extracted requirements; 14 linked SSRs; 2 linked open points. |
| Main Themes | Secure communication and freshness protection; Core ECA system behavior; Cybersecurity concept and evidence; System architecture design; Responsibility and customer approval model (showing 5 of 8) |
| Does Not Confirm | Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed. |
| Confidence | High |
| Evidence Basis | Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis. |
Key Conclusions From This PDF
- Confirmed by requirements: this data security container / secure data transfer standard contributes 90 Markdown-derived RFQ requirements with the strongest evidence in secure communication and freshness protection.
- Confirmed by requirements: supplier positioning is 4 accept; 43 accept with assumption; 39 partially accept; 4 informational only. The generated traceability links this document to 14 supplier system requirement records.
- Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. Do not convert these items into agreed baseline scope until the customer confirms the decision.
Critical Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Score | Category | Requirement / Reason | Supplier Position |
|---|---|---|---|---|
| REQ-AUTO-00994 | 77 | High risk due to unclear OEM/supplier responsibility | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00995 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01002 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01014 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01016 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01017 | 77 | High risk due to unclear OEM/supplier responsibility | Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data||PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data||TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3].security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01022 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01023 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01035 | 77 | High risk due to unclear OEM/supplier responsibility | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01041 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01042 | 77 | High risk due to unclear OEM/supplier responsibility | SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-01051 | 77 | High risk due to unclear OEM/supplier responsibility | 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 61 The server shall verify the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
Customer Clarifications / Open Points
Total Open Points2document-linked
P10priority
P20priority
Blocking Conceptyesyes/no
Blocking Estimationyesyes/no
Blocking SSRyesyes/no
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Open Point | Priority | Question / Impact | Required Customer Decision | Recommended Supplier Position | Owner | Status |
|---|---|---|---|---|---|---|
| OP-002 | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Implement configurable session/security-access on the ECU and request the customer-confirmed service-to-role table. | Shared (OEM policy / Supplier ECU) | Open | |
| OP-005 | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.Protected-signal design, key needs and runtime budget stay open; risk of unprotected critical signals. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | Support SecOC/SDT in the platform and request the customer-confirmed protected-signal list and freshness policy. | OEM / Customer | Open |
Requirements From This PDF
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Requirement / Proposal | Supplier Position | Review | Security Capability | Feature / Interface | SSR | Open Point | Source |
|---|---|---|---|---|---|---|---|---|
| REQ-AUTO-00994 | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | Diagnostic security | Secure communication and freshness protection; Diagnostic security None | SSR-RBAC-007 | OP-002 | 2 General page 6 Source detailsDocument section 2 General Section path 2 General Page reference page 6 |
| REQ-AUTO-00995 | SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-RBAC-007 | OP-002 | 2 General page 6 Source detailsDocument section 2 General Section path 2 General Page reference page 6 |
| REQ-AUTO-01002 | SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01014 | SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Key management | Secure communication and freshness protection; Key management None | SSR-KEY-006 | OP-005 | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01016 | SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-004 | OP-005 | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01017 | Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data||PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data||TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3].Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Key management | Secure communication and freshness protection; Key management None | SSR-KEY-006 | OP-005 | 3.2.1 HKDF Key Derivation page 11 Source detailsDocument section 3.2.1 HKDF Key Derivation Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.1 HKDF Key Derivation Page reference page 11 |
| REQ-AUTO-01022 | SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Key management | Secure communication and freshness protection; Key management None | SSR-KEY-006 | OP-005 | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01023 | SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Key management | Secure communication and freshness protection; Key management None | SSR-KEY-006 | OP-005 | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01035 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-DAI-005 | OP-005 | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01041 | SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-DAI-005 | OP-005 | 3.2.3 SDT_POLY1305 page 15 Source detailsDocument section 3.2.3 SDT_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 Page reference page 15 |
| REQ-AUTO-01042 | SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-DAI-005 | OP-005 | 3.2.3 SDT_POLY1305 page 15 Source detailsDocument section 3.2.3 SDT_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 Page reference page 15 |
| REQ-AUTO-01051 | 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 61 The server shall verify the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-004 | OP-005 | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01057 | SDT_REQ 67 Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1 Server’s Behaviour page 18 Source detailsDocument section 3.3.1 Server’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour Page reference page 18 |
| REQ-AUTO-01058 | Internal Page 19 (29) Figure 10 – Server's error and state handling SDT_REQ 68 At reception of an SDT request, if the security sub-layer is busy, the server shall respond with an SDT negative response using the NRC 0x21.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Secure communication | Secure communication and freshness protection; Cybersecurity requirement handling None | SSR-COM-008 | OP-005 | 3.3.1 Server’s Behaviour page 19 Source detailsDocument section 3.3.1 Server’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour Page reference page 19 |
| REQ-AUTO-01067 | SDT_REQ 76 The server shall update its state, (set PREQARC to the value received in the ANTIREPLAYCNT protocol element in the SDT request), if and only if it successfully verifies/decrypts the SDT request.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01068 | SDT_REQ 77 The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-DAI-005 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01075 | SDT_REQ 86 The client shall update its state, (set PRESARC to the value received in the ANTIREPLAYCNT protocol element in the SDT response), if and only if it successfully verifies/decrypts the SDT response (“C3”).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.2.1 Lost and Repeated SDT Messages page 23 Source detailsDocument section 3.3.2.1 Lost and Repeated SDT Messages Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour > 3.3.2.1 Lost and Repeated SDT Messages Page reference page 23 |
| REQ-AUTO-00997 | SDT_REQ 5 The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Application software behavior; Secure communication and freshness protection None | SSR-SYS-008 | OP-005 | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01000 | SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and PRESARC.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01003 | SDT_REQ 9 At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01006 | SDT_REQ 12 The server should populate the ANTIREPLAYCNT protocol element of the first response of an SDT sequence with the value zero (0), and set PRESARC accordingly.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.1 Anti-replay Protection and Transaction Coherency page 8 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 8 |
| REQ-AUTO-01007 | SDT_REQ 13 If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.1 Anti-replay Protection and Transaction Coherency page 8 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 8 |
| REQ-AUTO-01012 | SDT_REQ 18 In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01034 | 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 SDT_REQ 42 The server shall decrypt and verify the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01036 | SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01037 | Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the request with 16 (0x0010).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.2.2 Server Decryption/Encryption page 14 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 14 |
| REQ-AUTO-01038 | SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.2.2 Server Decryption/Encryption page 14 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 14 |
| REQ-AUTO-01052 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 63 The server shall authenticate the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string carried by the SIGMACBYTE protocol element of the corresponding request.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01053 | Internal Page 17 (29) SDT_REQ 64 The server shall populate the APAR protocol element in the response so that bit 5 is set to true.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.3.2 Server Verification/Authentication page 17 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 17 |
| REQ-AUTO-01054 | SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0010).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.2.3.2 Server Verification/Authentication page 17 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 17 |
| REQ-AUTO-01059 | SDT_REQ 69 At reception of an SDT request, if the requesting client is unauthenticated, the server shall respond with an SDT negative response using the NRC 0x34.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1 Server’s Behaviour page 19 Source detailsDocument section 3.3.1 Server’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour Page reference page 19 |
| REQ-AUTO-01060 | Internal Page 20 (29) SDT_REQ 70 At reception of an SDT request, if the request is too short or otherwise malformed, the server shall respond with an SDT negative response using the NRC 0x13.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01061 | SDT_REQ 71 At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01062 | SDT_REQ 88 At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01063 | SDT_REQ 72 At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01064 | SDT_REQ 73 At reception of an SDT request, if APAR is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01065 | SDT_REQ 74 At reception of an SDT request, if SIGLEN is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01066 | SDT_REQ 75 At reception of an SDT request, if the server fails to verify/decrypt the request, the server shall respond with an SDT negative response using the NRC 0x3A.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.1.1 SDT transactions with multiple responses page 20 Source detailsDocument section 3.3.1.1 SDT transactions with multiple responses Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour > 3.3.1.1 SDT transactions with multiple responses Page reference page 20 |
| REQ-AUTO-01076 | SDT_REQ 87 If the client determines an SDT request to be lost in transit, or, if it receives an SDT negative response with NRC BRR (0x21), the client shall • repeat the request byte for byte and leave state variables unchanged.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Partially Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | OP-005 | 3.3.2.1 Lost and Repeated SDT Messages page 23 Source detailsDocument section 3.3.2.1 Lost and Repeated SDT Messages Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour > 3.3.2.1 Lost and Repeated SDT Messages Page reference page 23 |
| REQ-AUTO-00991 | The keywords “shall”, “should”, “must” and so forth are used in this document and are to be interpreted in accordance with “Key words for use in RFCs to Indicate Requirement Levels” [10].Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Key management | Key management None | SSR-KEY-001 | - | 1.3 Document Quirks page 4 Source detailsDocument section 1.3 Document Quirks Section path 1 Introduction > 1.3 Document Quirks Page reference page 4 |
| REQ-AUTO-00992 | Internal Page 6 (29) 2 General SDT_REQ 1 The implementation of SDT (SecuredDataTransmission) shall follow the information provided in ISO14229-1 [1] chapter 16: Security sub-layer and in the TRATON Specification on Unified diagnostic Services (UDS) requirements [8].Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Diagnostic security | Secure communication and freshness protection; Diagnostic security None | SSR-RBAC-007 | - | 2 General page 6 Source detailsDocument section 2 General Section path 2 General Page reference page 6 |
| REQ-AUTO-01004 | SDT_REQ 10 At reception of an SDT response, the client shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PRESARC, and if the message can be otherwise verified, update PRESARC to reflect the new value, i.e.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01015 | SDT_REQ 21 At construction of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the client should re-run the KDF, and if and only if the authentication/encryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01018 | 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 SDT_REQ 24 ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state.Proposal: Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure communication and freshness protection None | SSR-RBAC-004 | - | 3.2.1 HKDF Key Derivation page 11 Source detailsDocument section 3.2.1 HKDF Key Derivation Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.1 HKDF Key Derivation Page reference page 11 |
| REQ-AUTO-01020 | SDT_REQ 26 info: The info argument to the HKDF function shall be set as the concatenation of the “SDT_0x84_KEY” octet string and the CipherScheme identifier.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure communication and freshness protection None | SSR-SYS-008 | - | 3.2.1 HKDF Key Derivation page 11 Source detailsDocument section 3.2.1 HKDF Key Derivation Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.1 HKDF Key Derivation Page reference page 11 |
| REQ-AUTO-01024 | Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 In subsequent sections (3.2.2.1 and 3.2.2.2) the following requirements shall be met: SDT_REQ 30 𝐾: The 𝐾 argument shall be the key octet string of 32 octets.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | Key management | Secure communication and freshness protection; Key management None | SSR-KEY-006 | - | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01028 | Internal Page 13 (29) 3.2.2.1 Client Encryption/Decryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 SDT_REQ 34 The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-DAI-005 | - | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01043 | Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 In subsequent sections (3.2.3.1 and 3.2.3.2), the following requirements shall be met: SDT_REQ 52 𝐾: The 𝐾 argument shall be the key octet string of 32 octets.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | Key management | Secure communication and freshness protection; Key management None | SSR-KEY-006 | - | 3.2.3 SDT_POLY1305 page 15 Source detailsDocument section 3.2.3 SDT_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 Page reference page 15 |
| REQ-AUTO-01045 | Internal Page 16 (29) 3.2.3.1 Client Authentication/Verification 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 54 The client shall authenticate the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT request, excluding the SIGMACBYTE protocol element.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection; Security evidence and traceability External Interfaces; OEM/Customer Review Interface | SSR-VV-005 | - | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01069 | SDT_REQ 78 The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | Authentication | Secure communication and freshness protection; Authentication None | SSR-DAI-005 | - | 3.3.2 Client’s Behaviour page 21 Source detailsDocument section 3.3.2 Client’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour Page reference page 21 |
| REQ-AUTO-00996 | (There may be more than one authentication state).Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 2 General page 6 Source detailsDocument section 2 General Section path 2 General Page reference page 6 |
| REQ-AUTO-00993 | SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 2 General page 6 Source detailsDocument section 2 General Section path 2 General Page reference page 6 |
| REQ-AUTO-00999 | the response shall be a properly formatted SDT positive 3 ISO 14299-1:2020 Clarifications and Deviations 3.1 Anti-replay Protection and Transaction Coherency SDT_INFO 5 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01001 | SDT_REQ 7 At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-01005 | Internal Page 8 (29) SDT_REQ 11 The client should populate the ANTIREPLAYCNT protocol element of the first request of an SDT sequence with the value zero (0), and set PREQARC accordingly.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.1 Anti-replay Protection and Transaction Coherency page 8 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 8 |
| REQ-AUTO-01008 | SDT_REQ 14 The client shall maintain the state variable PREQTAG.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2 Authenticity and Confidentiality page 9 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 9 |
| REQ-AUTO-01009 | SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2 Authenticity and Confidentiality page 9 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 9 |
| REQ-AUTO-01010 | SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01011 | SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01019 | SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet string (null).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure communication and freshness protection None | SSR-SYS-008 | - | 3.2.1 HKDF Key Derivation page 11 Source detailsDocument section 3.2.1 HKDF Key Derivation Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.1 HKDF Key Derivation Page reference page 11 |
| REQ-AUTO-01021 | SDT_REQ 27 The L argument to the HKDF function shall be set to 64.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure communication and freshness protection None | SSR-SYS-008 | - | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01025 | SDT_REQ 31 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01026 | SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01027 | SDT_REQ 33 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.2 SDT_AEAD_CHACHA20_POLY1305 page 12 Source detailsDocument section 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page reference page 12 |
| REQ-AUTO-01029 | SDT_REQ 35 The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01030 | SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01031 | SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01032 | SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01033 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: SDT_REQ 39 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN, ANTIREPLAYCNT protocol elements of the response and the value stored in the state variable PREQTAG.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.2.2 Server Decryption/Encryption page 13 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 13 |
| REQ-AUTO-01039 | one octet, and the rest should go in the SRVSPECPARAM protocol element.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | External interfaces External Interfaces | SSR-COM-002 | - | 3.2.2.2 Server Decryption/Encryption page 14 Source detailsDocument section 3.2.2.2 Server Decryption/Encryption Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.2 SDT_AEAD_CHACHA20_POLY1305 > 3.2.2.2 Server Decryption/Encryption Page reference page 14 |
| REQ-AUTO-01040 | SDT_REQ 49 The L argument to the HKDF function shall be set to 64.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure communication and freshness protection None | SSR-SYS-008 | - | 3.2.3 SDT_POLY1305 page 15 Source detailsDocument section 3.2.3 SDT_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 Page reference page 15 |
| REQ-AUTO-01044 | SDT_REQ 91 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2.3 SDT_POLY1305 page 15 Source detailsDocument section 3.2.3 SDT_POLY1305 Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 Page reference page 15 |
| REQ-AUTO-01046 | SDT_REQ 55 The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01047 | SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010).Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01048 | SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01049 | SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01050 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 59 The client shall verify the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string stored in the state variable PREQTAG.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.3.2 Server Verification/Authentication page 16 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 16 |
| REQ-AUTO-01055 | SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure communication and freshness protection External Interfaces | SSR-COM-002 | - | 3.2.3.2 Server Verification/Authentication page 17 Source detailsDocument section 3.2.3.2 Server Verification/Authentication Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality > 3.2.3 SDT_POLY1305 > 3.2.3.2 Server Verification/Authentication Page reference page 17 |
| REQ-AUTO-01070 | Internal Page 22 (29) Figure 12 – The client's error and state handling SDT_REQ 79 At reception of an SDT response, if the client is unauthenticated, the client shall discard the SDT_REQ 80 At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.3.2 Client’s Behaviour page 22 Source detailsDocument section 3.3.2 Client’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour Page reference page 22 |
| REQ-AUTO-01071 | SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard theProposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.3.2 Client’s Behaviour page 22 Source detailsDocument section 3.3.2 Client’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour Page reference page 22 |
| REQ-AUTO-01072 | Internal Page 23 (29) SDT_REQ 82 At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the SDT_REQ 83 At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.3.2.1 Lost and Repeated SDT Messages page 23 Source detailsDocument section 3.3.2.1 Lost and Repeated SDT Messages Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour > 3.3.2.1 Lost and Repeated SDT Messages Page reference page 23 |
| REQ-AUTO-01073 | SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.3.2.1 Lost and Repeated SDT Messages page 23 Source detailsDocument section 3.3.2.1 Lost and Repeated SDT Messages Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour > 3.3.2.1 Lost and Repeated SDT Messages Page reference page 23 |
| REQ-AUTO-01074 | SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response.Proposal: Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Accept with Assumption | Proposal Ready | None | System behavior; Secure communication and freshness protection None | SSR-SYS-006 | - | 3.3.2.1 Lost and Repeated SDT Messages page 23 Source detailsDocument section 3.3.2.1 Lost and Repeated SDT Messages Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.2 Client’s Behaviour > 3.3.2.1 Lost and Repeated SDT Messages Page reference page 23 |
| REQ-AUTO-01013 | SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Secure communication and freshness protection None | None | - | 3.2 Authenticity and Confidentiality page 10 Source detailsDocument section 3.2 Authenticity and Confidentiality Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.2 Authenticity and Confidentiality Page reference page 10 |
| REQ-AUTO-01056 | The SDT positive response may of course contain an encapsulated negative UDS response.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Secure communication and freshness protection None | None | - | 3.3.1 Server’s Behaviour page 18 Source detailsDocument section 3.3.1 Server’s Behaviour Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.3 Error- and state-handling > 3.3.1 Server’s Behaviour Page reference page 18 |
| REQ-AUTO-00987 | The User shall apply the latest version of this CVS32.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-006 | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| REQ-AUTO-00989 | Any review of CVS32 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-009 | - | page-2 Page 2 page 2 Source detailsDocument section page-2 Page 2 Section path Page 2 Page reference page 2 |
| REQ-AUTO-00990 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-003 | - | page-2 Page 2 page 2 Source detailsDocument section page-2 Page 2 Section path Page 2 Page reference page 2 |
| REQ-AUTO-00998 | The server shall respond with application layer NRC 0x39, i.e.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 3.1 Anti-replay Protection and Transaction Coherency page 7 Source detailsDocument section 3.1 Anti-replay Protection and Transaction Coherency Section path 3 ISO 14299-1:2020 Clarifications and Deviations > 3.1 Anti-replay Protection and Transaction Coherency Page reference page 7 |
| REQ-AUTO-00988 | Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | page-2 Page 2 page 2 Source detailsDocument section page-2 Page 2 Section path Page 2 Page reference page 2 |
Derived Supplier System Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| SSR | Statement / Trace | Feature | Security Capability | Interface | Responsibility | Status | Verification |
|---|---|---|---|---|---|---|---|
| SSR-COM-002 | External Interfaces — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for External Interfaces, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00999; REQ-AUTO-01001; REQ-AUTO-01004; REQ-AUTO-01005; REQ-AUTO-01009; REQ-AUTO-01011; REQ-AUTO-01027; REQ-AUTO-01029; REQ-AUTO-01030; REQ-AUTO-01031; REQ-AUTO-01033; REQ-AUTO-01039; REQ-AUTO-01046; REQ-AUTO-01047; REQ-AUTO-01048; REQ-AUTO-01050; REQ-AUTO-01055. This SSR is also supported by requirements from other PDFs. | External Interfaces | None | External Interfaces | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-COM-006 | Secure communication and freshness protection — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-01000; REQ-AUTO-01002; REQ-AUTO-01003; REQ-AUTO-01006; REQ-AUTO-01007; REQ-AUTO-01012; REQ-AUTO-01034; REQ-AUTO-01036; REQ-AUTO-01037; REQ-AUTO-01038; REQ-AUTO-01052; REQ-AUTO-01053; REQ-AUTO-01054; REQ-AUTO-01057; REQ-AUTO-01059; REQ-AUTO-01060; REQ-AUTO-01061; REQ-AUTO-01062; REQ-AUTO-01063; REQ-AUTO-01064; REQ-AUTO-01065; REQ-AUTO-01066; REQ-AUTO-01067; REQ-AUTO-01075; REQ-AUTO-01076. This SSR is also supported by requirements from other PDFs. | Secure communication and freshness protection | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-COM-008 | Secure communication and freshness protection — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-01058. | Secure communication and freshness protection | Secure communication | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-DAI-005 | Secure communication and freshness protection — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Secure communication and freshness protection data and reject manipulated or unauthenticated data.From this PDF: REQ-AUTO-01028; REQ-AUTO-01035; REQ-AUTO-01041; REQ-AUTO-01042; REQ-AUTO-01068; REQ-AUTO-01069. | Secure communication and freshness protection | Authentication | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-KEY-001 | Key management — Key and Certificate HandlingThe ECU shall manage key and certificate material for Key management across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-00991. This SSR is also supported by requirements from other PDFs. | Key management | Key management | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-KEY-006 | Secure communication and freshness protection — Key and Certificate HandlingThe ECU shall manage key and certificate material for Secure communication and freshness protection across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-01014; REQ-AUTO-01017; REQ-AUTO-01022; REQ-AUTO-01023; REQ-AUTO-01024; REQ-AUTO-01043. | Secure communication and freshness protection | Key management | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-004 | Application software behavior — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-01018. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-007 | Secure communication and freshness protection — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Secure communication and freshness protection, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00992; REQ-AUTO-00994; REQ-AUTO-00995. | Secure communication and freshness protection | Diagnostic security | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-SYS-006 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00987; REQ-AUTO-00993; REQ-AUTO-01008; REQ-AUTO-01010; REQ-AUTO-01015; REQ-AUTO-01025; REQ-AUTO-01026; REQ-AUTO-01032; REQ-AUTO-01044; REQ-AUTO-01049; REQ-AUTO-01070; REQ-AUTO-01071; REQ-AUTO-01072; REQ-AUTO-01073; REQ-AUTO-01074. This SSR is also supported by requirements from other PDFs. | System behavior | None | None | Shared | Ready for Customer Alignment | Test |
| SSR-SYS-008 | Application software behavior — System FunctionThe ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00997; REQ-AUTO-00998; REQ-AUTO-01019; REQ-AUTO-01020; REQ-AUTO-01021; REQ-AUTO-01040. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-SYS-009 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00989. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test |
| SSR-TOOL-003 | Backend and IT integration — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.From this PDF: REQ-AUTO-00990. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Ready for Customer Alignment | Review + Test |
| SSR-VV-004 | Secure communication and freshness protection — Verification and ValidationThe supplier shall verify and validate Secure communication and freshness protection per the agreed cybersecurity verification and validation plan.From this PDF: REQ-AUTO-01016; REQ-AUTO-01051. | Secure communication and freshness protection | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-VV-005 | External interfaces — Verification and ValidationThe supplier shall verify and validate External interfaces per the agreed cybersecurity verification and validation plan.From this PDF: REQ-AUTO-01045. | External interfaces | None | External Interfaces | Supplier-Owned | Candidate | Review + Test |
System / Security Design Impact
| Impact Area | Evidence From This PDF |
|---|---|
| Impacted system features | Application software behavior; Application software behavior; Secure communication and freshness protection; Backend and IT integration; External interfaces; External interfaces; Secure communication and freshness protection; External interfaces; Secure communication and freshness protection; Security evidence and traceability; Key management; Secure communication and freshness protection; Secure communication and freshness protection; Authentication; Secure communication and freshness protection; Backend and IT integration; Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability; Secure communication and freshness protection; Cybersecurity requirement handling (showing 12 of 16) |
| Impacted interfaces | External Interfaces; External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface |
| Impacted security capabilities | Authentication; Diagnostic security; Key management; Secure communication |
| Impacted architecture elements | Application Software; Backend and IT Systems; Backend and IT Systems; OEM/Customer Review Interface; Compliance Process; External Interfaces; External Interfaces; OEM/Customer Review Interface; Security Services; System Core |
| Impacted work products | Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; Requirement traceability record; System/architecture design |
| Tools / IT / hardware / test | High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Low/Low/Medium; Medium/High/Medium; Medium/Low/Medium |
| Design assumptions introduced | Security-relevant requirement the ECU can own once responsibility/method is confirmed. |
| Design decisions required | Agree responsibility split (DIA) for the non-ECU portion. |
Estimation / Resource / Tooling Impact
| Impact | Status |
|---|---|
| Estimation impact | yes |
| Resource/tool/IT/HW/test impact | High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Low/Low/Medium; Medium/High/Medium; Medium/Low/Medium |
Document Impact Diagram
Document Impact
Generated from document-specific requirement, traceability, SSR, and open-point evidence.
flowchart LR
doc["CVS32.pdf"]
d0["Authentication"]
doc --> d0
d1["Diagnostic security"]
doc --> d1
d2["Key management"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Application software behavior; Secure communication and freshness protection"]
doc --> f1
f2["Feature: Backend and IT integration"]
doc --> f2
i0["Interface: External Interfaces"]
doc --> i0
i1["Interface: External Interfaces; OEM/Customer Review Interface"]
doc --> i1
i2["Interface: OEM/Customer Review Interface"]
doc --> i2
s0["SSR: SSR-COM-002"]
doc --> s0
s1["SSR: SSR-COM-006"]
doc --> s1
s2["SSR: SSR-COM-008"]
doc --> s2
o0["Open point: OP-002"]
doc --> o0
o1["Open point: OP-005"]
doc --> o1
Mermaid source
flowchart LR
doc["CVS32.pdf"]
d0["Authentication"]
doc --> d0
d1["Diagnostic security"]
doc --> d1
d2["Key management"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Application software behavior; Secure communication and freshness protection"]
doc --> f1
f2["Feature: Backend and IT integration"]
doc --> f2
i0["Interface: External Interfaces"]
doc --> i0
i1["Interface: External Interfaces; OEM/Customer Review Interface"]
doc --> i1
i2["Interface: OEM/Customer Review Interface"]
doc --> i2
s0["SSR: SSR-COM-002"]
doc --> s0
s1["SSR: SSR-COM-006"]
doc --> s1
s2["SSR: SSR-COM-008"]
doc --> s2
o0["Open point: OP-002"]
doc --> o0
o1["Open point: OP-005"]
doc --> o1
Traceability
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Customer Requirement | SSR | Disposition | Confidence | Reason |
|---|---|---|---|---|
| REQ-AUTO-00987 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00988 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00989 | SSR-SYS-009 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00990 | SSR-TOOL-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00991 | SSR-KEY-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00992 | SSR-RBAC-007 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00993 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00994 | SSR-RBAC-007 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00995 | SSR-RBAC-007 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00996 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00997 | SSR-SYS-008 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00998 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00999 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01000 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01001 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01002 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01003 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01004 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01005 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01006 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01007 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01008 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01009 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01010 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01011 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01012 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01013 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-01014 | SSR-KEY-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01015 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01016 | SSR-VV-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01017 | SSR-KEY-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01018 | SSR-RBAC-004 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01019 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01020 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01021 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01022 | SSR-KEY-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01023 | SSR-KEY-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01024 | SSR-KEY-006 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01025 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01026 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01027 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01028 | SSR-DAI-005 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-01029 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01030 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01031 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01032 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01033 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01034 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01035 | SSR-DAI-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01036 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01037 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01038 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01039 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01040 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01041 | SSR-DAI-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01042 | SSR-DAI-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01043 | SSR-KEY-006 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01044 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01045 | SSR-VV-005 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-01046 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01047 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01048 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01049 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01050 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01051 | SSR-VV-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01052 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01053 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01054 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01055 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01056 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-01057 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01058 | SSR-COM-008 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01059 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01060 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01061 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01062 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01063 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01064 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01065 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01066 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01067 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01068 | SSR-DAI-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01069 | SSR-DAI-005 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01070 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01071 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01072 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01073 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01074 | SSR-SYS-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-01075 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-01076 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
Detailed Evidence
Document intelligence markdown
CVS32
- Source PDF:
customer-input/pdf/CVS32.pdf - Converted Markdown:
converted/markdown/CVS32.md - Document type: Data Security Container / Secure Data Transfer Standard
- Domain: Secure Data Transfer
- Confidence: High
- Evidence basis: Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis.
Executive Summary
Confirmed by requirements: this data security container / secure data transfer standard contributes 90 Markdown-derived RFQ requirements with the strongest evidence in secure communication and freshness protection. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence.
Confirmed by requirements: supplier positioning is 4 accept; 43 accept with assumption; 39 partially accept; 4 informational only. The generated traceability links this document to 14 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Document Abstract
| Field | Interpretation |
|---|---|
| Document Purpose | Confirmed by requirements: this data security container / secure data transfer standard contributes 90 Markdown-derived RFQ requirements with the strongest evidence in secure communication and freshness protection. |
| Engineering Interpretation | Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence. |
| Supplier Proposal Impact | Confirmed by requirements: supplier positioning is 4 accept; 43 accept with assumption; 39 partially accept; 4 informational only. The generated traceability links this document to 14 supplier system requirement records. |
| System / Security Impact | Inferred from mapped features, capabilities, and interfaces: the main design/security impact is secure communication and freshness protection; core eca system behavior; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them. |
| Customer Clarification Impact | Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. Do not convert these items into agreed baseline scope until the customer confirms the decision. |
| Confidence and Limits | Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed. |
Main Requirement Themes
| Theme | Summary | Requirement Count | Representative Requirements |
|---|---|---|---|
| Secure communication and freshness protection | Defines protected communication behavior, freshness/replay checks, and signal or PDU allocation dependencies. | 82 | REQ-AUTO-00992; REQ-AUTO-00993; REQ-AUTO-00994 |
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 71 | REQ-AUTO-00987; REQ-AUTO-00988; REQ-AUTO-00989 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 47 | REQ-AUTO-00989; REQ-AUTO-00990; REQ-AUTO-00991 |
| System architecture design | Groups related document requirements into a single engineering theme. | 44 | REQ-AUTO-00987; REQ-AUTO-00988; REQ-AUTO-00993 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 33 | REQ-AUTO-00989; REQ-AUTO-00990; REQ-AUTO-00992 |
| System | Groups related document requirements into a single engineering theme. | 19 | REQ-AUTO-00987; REQ-AUTO-00988; REQ-AUTO-00993 |
| External interfaces | Groups related document requirements into a single engineering theme. | 18 | REQ-AUTO-00999; REQ-AUTO-01001; REQ-AUTO-01004 |
| Interface | Groups related document requirements into a single engineering theme. | 18 | REQ-AUTO-00999; REQ-AUTO-01001; REQ-AUTO-01004 |
Document Content Structure
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 1 Introduction | 1 | 0 | 0 | 1 |
| -- 1.3 Document Quirks | 1 | 0 | 0 | 1 |
| 2 General | 5 | 2 | 1 | 2 |
| 3 ISO 14299-1:2020 Clarifications and Deviations | 80 | 37 | 1 | 10 |
| -- 3.1 Anti-replay Protection and Transaction Coherency | 11 | 6 | 1 | 3 |
| -- 3.2 Authenticity and Confidentiality | 48 | 17 | 1 | 9 |
| -- -- 3.2.1 HKDF Key Derivation | 4 | 1 | 1 | 3 |
| -- -- 3.2.2 SDT_AEAD_CHACHA20_POLY1305 | 19 | 7 | 1 | 6 |
| -- -- -- 3.2.2.2 Server Decryption/Encryption | 12 | 5 | 1 | 4 |
| -- -- 3.2.3 SDT_POLY1305 | 16 | 6 | 1 | 8 |
| -- -- -- 3.2.3.2 Server Verification/Authentication | 11 | 4 | 1 | 5 |
| -- 3.3 Error- and state-handling | 21 | 14 | 1 | 4 |
| -- -- 3.3.1 Server’s Behaviour | 13 | 12 | 1 | 3 |
| -- -- -- 3.3.1.1 SDT transactions with multiple responses | 9 | 9 | 1 | 2 |
| -- -- 3.3.2 Client’s Behaviour | 8 | 2 | 1 | 3 |
| -- -- -- 3.3.2.1 Lost and Repeated SDT Messages | 5 | 2 | 1 | 2 |
What this document does not confirm
Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed.
Critical Requirements
| ID | Score | Category | Reason | Statement |
|---|---|---|---|---|
| REQ-AUTO-00994 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. |
| REQ-AUTO-00995 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey. |
| REQ-AUTO-01002 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e. |
| REQ-AUTO-01014 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. |
| REQ-AUTO-01016 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values. |
| REQ-AUTO-01017 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data//PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data//TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3]. |
| REQ-AUTO-01022 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request. |
| REQ-AUTO-01023 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response. |
| REQ-AUTO-01035 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request. |
| REQ-AUTO-01041 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request. |
Open Points
| Open Point | Priority | Question | Impact | Status |
|---|---|---|---|---|
| OP-002 | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Open | |
| OP-005 | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | Protected-signal design, key needs and runtime budget stay open; risk of unprotected critical signals. | Open |
Supplier System Requirements
| SSR | Title | Statement | Reqs From This PDF | Other PDFs | Status |
|---|---|---|---|---|---|
| SSR-COM-002 | External Interfaces — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for External Interfaces, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-00999; REQ-AUTO-01001; REQ-AUTO-01004; REQ-AUTO-01005; REQ-AUTO-01009; REQ-AUTO-01011; REQ-AUTO-01027; REQ-AUTO-01029; REQ-AUTO-01030; REQ-AUTO-01031; REQ-AUTO-01033; REQ-AUTO-01039; REQ-AUTO-01046; REQ-AUTO-01047; REQ-AUTO-01048; REQ-AUTO-01050; REQ-AUTO-01055 | yes | Blocked by Customer Clarification |
| SSR-COM-006 | Secure communication and freshness protection — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-01000; REQ-AUTO-01002; REQ-AUTO-01003; REQ-AUTO-01006; REQ-AUTO-01007; REQ-AUTO-01012; REQ-AUTO-01034; REQ-AUTO-01036; REQ-AUTO-01037; REQ-AUTO-01038; REQ-AUTO-01052; REQ-AUTO-01053; REQ-AUTO-01054; REQ-AUTO-01057; REQ-AUTO-01059; REQ-AUTO-01060; REQ-AUTO-01061; REQ-AUTO-01062; REQ-AUTO-01063; REQ-AUTO-01064; REQ-AUTO-01065; REQ-AUTO-01066; REQ-AUTO-01067; REQ-AUTO-01075; REQ-AUTO-01076 | yes | Blocked by Customer Clarification |
| SSR-COM-008 | Secure communication and freshness protection — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-01058 | no | Blocked by Customer Clarification |
| SSR-DAI-005 | Secure communication and freshness protection — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Secure communication and freshness protection data and reject manipulated or unauthenticated data. | REQ-AUTO-01028; REQ-AUTO-01035; REQ-AUTO-01041; REQ-AUTO-01042; REQ-AUTO-01068; REQ-AUTO-01069 | no | Blocked by Customer Clarification |
| SSR-KEY-001 | Key management — Key and Certificate Handling | The ECU shall manage key and certificate material for Key management across provisioning, storage, use, renewal and revocation per the agreed key lifecycle. | REQ-AUTO-00991 | yes | Blocked by Customer Clarification |
| SSR-KEY-006 | Secure communication and freshness protection — Key and Certificate Handling | The ECU shall manage key and certificate material for Secure communication and freshness protection across provisioning, storage, use, renewal and revocation per the agreed key lifecycle. | REQ-AUTO-01014; REQ-AUTO-01017; REQ-AUTO-01022; REQ-AUTO-01023; REQ-AUTO-01024; REQ-AUTO-01043 | no | Blocked by Customer Clarification |
| SSR-RBAC-004 | Application software behavior — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-01018 | yes | Blocked by Customer Clarification |
| SSR-RBAC-007 | Secure communication and freshness protection — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Secure communication and freshness protection, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00992; REQ-AUTO-00994; REQ-AUTO-00995 | no | Blocked by Customer Clarification |
| SSR-SYS-006 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00987; REQ-AUTO-00993; REQ-AUTO-01008; REQ-AUTO-01010; REQ-AUTO-01015; REQ-AUTO-01025; REQ-AUTO-01026; REQ-AUTO-01032; REQ-AUTO-01044; REQ-AUTO-01049; REQ-AUTO-01070; REQ-AUTO-01071; REQ-AUTO-01072; REQ-AUTO-01073; REQ-AUTO-01074 | yes | Ready for Customer Alignment |
| SSR-SYS-008 | Application software behavior — System Function | The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00997; REQ-AUTO-00998; REQ-AUTO-01019; REQ-AUTO-01020; REQ-AUTO-01021; REQ-AUTO-01040 | yes | Blocked by Customer Clarification |
| SSR-SYS-009 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00989 | yes | Candidate |
| SSR-TOOL-003 | Backend and IT integration — Tooling / IT / Evidence Storage | The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration. | REQ-AUTO-00990 | yes | Ready for Customer Alignment |
| SSR-VV-004 | Secure communication and freshness protection — Verification and Validation | The supplier shall verify and validate Secure communication and freshness protection per the agreed cybersecurity verification and validation plan. | REQ-AUTO-01016; REQ-AUTO-01051 | no | Blocked by Customer Clarification |
| SSR-VV-005 | External interfaces — Verification and Validation | The supplier shall verify and validate External interfaces per the agreed cybersecurity verification and validation plan. | REQ-AUTO-01045 | no | Candidate |
Design Impact
- Impacted System Features: Application software behavior; Application software behavior; Secure communication and freshness protection; Backend and IT integration; External interfaces; External interfaces; Secure communication and freshness protection; External interfaces; Secure communication and freshness protection; Security evidence and traceability; Key management; Secure communication and freshness protection (showing 8 of 16)
- Impacted Interfaces: External Interfaces; External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface
- Impacted Security Capabilities: Authentication; Diagnostic security; Key management; Secure communication
- Impacted Architecture Elements: Application Software; Backend and IT Systems; Backend and IT Systems; OEM/Customer Review Interface; Compliance Process; External Interfaces; External Interfaces; OEM/Customer Review Interface; Security Services; System Core
- Impacted Work Products: Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; Requirement traceability record; System/architecture design
- Impacted Tools It Hardware Test: High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Low/Low/Medium; Medium/High/Medium (showing 8 of 9)
- Impacted Supplier System Requirements: SSR-COM-002; SSR-COM-006; SSR-COM-008; SSR-DAI-005; SSR-KEY-001; SSR-KEY-006; SSR-RBAC-004; SSR-RBAC-007 (showing 8 of 14)
- Design Assumptions Introduced: Security-relevant requirement the ECU can own once responsibility/method is confirmed.
- Design Decisions Required: Agree responsibility split (DIA) for the non-ECU portion.