CVS32.pdf · Data Security Container / Secure Data Transfer Standard · Secure Data Transfer
CVS32.pdf · Data Security Container / Secure Data Transfer Standard · Secure Data Transfer
Systems-engineering read of what this document defines for the system - scope, boundaries, interfaces, obligations, and what is still open.
Scope: this data security container / secure data transfer standard specifies secure communication and freshness protection, covering 1 Introduction; 1.3 Document Quirks; 2 General; 3 ISO 14299-1:2020 Clarifications and Deviations; 3.1 Anti-replay Protection and Transaction Coherency; 3.2 Authenticity and Confidentiality.
System boundary and interfaces: the document constrains 1 interface(s) - OEM/Customer Review Interface; principal functions in scope are Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability.
Design and security impact: affects Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability; security capabilities touched: Key management; Diagnostic security; Authentication; Secure communication; 11 supplier system requirement(s) were derived from this document.
Open for the customer: 5 document-linked open point(s) - mainly Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. (sample: 3 of 5) - plus 6 unidentified requirement-like statement(s). Do not baseline these until the customer confirms.
Confidence and limits: High confidence. Categorisation is derived from the converted Markdown (customer IDs, normative wording, and section context); no OCR or downstream PDF analysis is used.
| 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. | 193 | RFQX-CVS32-0007; RFQX-CVS32-0009; RFQX-CVS32-0010 |
| System architecture design | Groups related document requirements into a single engineering theme. | 135 | RFQX-CVS32-0001; RFQX-CVS32-0002; RFQX-CVS32-0009 |
| Requirement | Groups related document requirements into a single engineering theme. | 121 | RFQX-CVS32-0007; RFQX-CVS32-0009; RFQX-CVS32-0012 |
| System | Groups related document requirements into a single engineering theme. | 100 | RFQX-CVS32-0001; RFQX-CVS32-0002; RFQX-CVS32-0009 |
| Information | Groups related document requirements into a single engineering theme. | 74 | RFQX-CVS32-0006; RFQX-CVS32-0010; RFQX-CVS32-0011 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 69 | RFQX-CVS32-0003; RFQX-CVS32-0004; RFQX-CVS32-0005 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 46 | RFQX-CVS32-0003; RFQX-CVS32-0004; RFQX-CVS32-0005 |
| Cybersecurity | Groups related document requirements into a single engineering theme. | 27 | RFQX-CVS32-0005; RFQX-CVS32-0006; RFQX-CVS32-0007 |
| Section | Requirements | Information | Unknown / Review Needed | Total Items | Critical | Open Points | SSR Links |
|---|---|---|---|---|---|---|---|
| 1 Introduction | 1 | 1 | 0 | 4 | 2 | 2 | 1 |
| -- 1.3 Document Quirks | 1 | 1 | 0 | 4 | 2 | 2 | 1 |
| 2 General | 4 | 4 | 0 | 9 | 2 | 1 | 2 |
| 3 ISO 14299-1:2020 Clarifications and Deviations | 87 | 48 | 0 | 136 | 38 | 2 | 10 |
| -- 3.1 Anti-replay Protection and Transaction Coherency | 11 | 9 | 0 | 21 | 7 | 2 | 3 |
| -- 3.2 Authenticity and Confidentiality | 53 | 22 | 0 | 75 | 17 | 1 | 9 |
| -- -- 3.2.1 HKDF Key Derivation | 4 | 3 | 0 | 7 | 1 | 0 | 3 |
| -- -- 3.2.2 SDT_AEAD_CHACHA20_POLY1305 | 20 | 8 | 0 | 28 | 7 | 1 | 6 |
| -- -- -- 3.2.2.2 Server Decryption/Encryption | 13 | 4 | 0 | 17 | 5 | 1 | 4 |
| -- -- 3.2.3 SDT_POLY1305 | 20 | 4 | 0 | 24 | 6 | 1 | 7 |
| -- -- -- 3.2.3.2 Server Verification/Authentication | 13 | 2 | 0 | 15 | 4 | 1 | 4 |
| -- 3.3 Error- and state-handling | 23 | 17 | 0 | 40 | 14 | 1 | 4 |
| -- -- 3.3.1 Server’s Behaviour | 12 | 10 | 0 | 22 | 12 | 1 | 3 |
| -- -- -- 3.3.1.1 SDT transactions with multiple responses | 9 | 5 | 0 | 14 | 9 | 1 | 2 |
| -- -- 3.3.2 Client’s Behaviour | 11 | 7 | 0 | 18 | 2 | 1 | 3 |
| -- -- -- 3.3.2.1 Lost and Repeated SDT Messages | 7 | 4 | 0 | 11 | 2 | 1 | 2 |
| 4 Referenced documents and IT-Systems | 29 | 21 | 0 | 50 | 0 | 0 | 0 |
Tables are reconstructed column-correct from the document text layer (no OCR). Diagrams are linked from converted image assets.
| Abbreviation | Description | ||
|---|---|---|---|
| ECU | Electronic Control Unit | ||
| ID, id, Id | Identifier | ||
| N/A | Not Applicable | ||
| MAC | Message Authentication Code | ||
| HMAC | Hash-based Message Authentication Code | ||
| HKDF | HMAC-based Key Derivation Function | ||
| SDT | SecuredDataTransmission | ||
| NRC | Negative Response Code |
| Abbreviation | Description | ||
|---|---|---|---|
| ECU | Electronic Control Unit | ||
| ID, id, Id | Identifier | ||
| N/A | Not Applicable | ||
| MAC | Message Authentication Code | ||
| HMAC | Hash-based Message Authentication Code | ||
| HKDF | HMAC-based Key Derivation Function | ||
| SDT | SecuredDataTransmission | ||
| NRC | Negative Response Code | ||
| TAG | Typically a MAC or similar. A cryptographic element used to ensure authenticity. Carried in the SIGMACBYTE protocol element. | ||
| PREQARC | State variable. Previous REQuest Anti-Replay Counter. The ANTIREPLAYCNT used by the client in the previous SDT request. | ||
| PRESARC | State variable. Previous RESponse Anti-Replay Counter. The ANTIREPLAYCNT used by the server in the previous SDT response. | ||
| PREQTAG | State variable. Previous REQuest TAG. The TAG from the previous SDT request. | ||
| PSIGENCRYPT | State variable. Previous SIGENCRYPT. The SIGENCRYPT used in the previous SDT transaction. | ||
| PKEY | State variable. Previous KEY. The key used in the previous SDT transaction. Covaries with PSIGENCRYPT. |
Security protocol or cryptographic context
| CipherScheme | SIGENCRYPT |
|---|---|
| Reserved by vehicle manufacturer | 0 - 1 |
| SDT_AEAD_CHACHA20_POLY1305 | 2 |
| SDT_POLY1305 | 3 |
| Reserved by vehicle manufacturer | 4 - 127 |
| Reserved by system supplier | 128 - 143 |
| Reserved by ISO | 144 – 255 |
Security protocol or cryptographic context
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Diagnostic parameter or service behavior
Security protocol or cryptographic context
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
| Field | Value |
|---|---|
| Source PDF | CVS32.pdf |
| Document Type | Data Security Container / Secure Data Transfer Standard |
| Domain | Secure Data Transfer |
| Scope Summary | 121 confirmed requirements, 6 needing clarification, 74 information, 2 reference items; 11 linked SSRs; 5 linked open points. |
| Main Themes | Secure communication and freshness protection; System architecture design; Requirement; System; Information (sample: 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. |
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Score | Category | Requirement / Reason | Supplier Position |
|---|---|---|---|---|
| RFQX-CVS32-0008 | 95 | High risk due to unclear OEM/supplier responsibility | 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].security relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS32-0014 | 95 | 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; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | Needs Customer Clarification |
| 1.3 | 77 | High risk due to unclear OEM/supplier responsibility | The mnemonics defined in the ISO14229-1:2020 [1] standard are reused throughout this document. Some paragraphs in this document includes pseudo code. The pseudo code make use of the following notation: 𝑋 || 𝑌 The concatenation of the octet strings 𝑋 and 𝑌 𝑋𝑠𝑒𝑟𝑣𝑒𝑟 𝑋 is owned by the Server 𝑋𝑐𝑙𝑖𝑒𝑛𝑡 𝑋 is owned by the Client The first occurrence of an abbreviation or term in this document will appear italicized to indicate that it is explained in section 1.4 Abbreviations or section 1.5 Terminology. All paragraphs from here on in this document are assigned unique tags, composed of a prefix and an identification number for non-ambiguous identification. SDT_REQ X identifies a requirement, and tag SDT_INFO X is used to denote informational text. Whether a requirement refers to client-side or server-side behavior is clear from the context and the requirement text itself. 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].security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| SDT_REQ 4 | 77 | High risk due to unclear OEM/supplier responsibility | 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 |
| SDT_REQ 8 | 77 | High risk due to unclear OEM/supplier responsibility | 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 |
| SDT_REQ 20 | 77 | High risk due to unclear OEM/supplier responsibility | 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 |
| SDT_REQ 22 | 77 | High risk due to unclear OEM/supplier responsibility | 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 |
| SDT_REQ 61 | 77 | High risk due to unclear OEM/supplier responsibility | 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 |
| SDT_REQ 76 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| SDT_REQ 77 | 77 | High risk due to unclear OEM/supplier responsibility | The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”).security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| SDT_REQ 86 | 77 | High risk due to unclear OEM/supplier responsibility | 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”).security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| RFQX-CVS32-0001 | 66 | High risk due to unclear OEM/supplier responsibility | The User shall apply the latest version of this CVS32.architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.
Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.
Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.
Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.
Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline.
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-004 | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.Update-control scope and evidence ownership stay open; risk of an unprotected update path. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Implement authenticated, integrity-protected ECU programming with controlled boot/app state; require OEM update-chain definition. | Shared (OEM backend / 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 | |
| OP-009 | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case. | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Deliver supplier-owned work products per concept; require a signed DIA/RASIC before treating shared items as supplier scope. | OEM / Customer + Supplier (DIA) | Open | |
| OP-011 | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline.Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Decide whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context. | Carry the items as customer-confirmation dependencies and review them in the next clarification workshop. | OEM / Customer | Open |
Items carrying a customer requirement ID and a normative (shall/must) statement.
Document Quirks The mnemonics defined in the ISO14229-1:2020 [1] standard are reused throughout this document. Some paragraphs in this document includes pseudo code. The pseudo code make use of the following notation: 𝑋 || 𝑌 The concatenation of the octet strings 𝑋 and 𝑌 𝑋𝑠𝑒𝑟𝑣𝑒𝑟 𝑋 is owned by the Server 𝑋𝑐𝑙𝑖𝑒𝑛𝑡 𝑋 is owned by the Client The first occurrence of an abbreviation or term in this document will appear italicized to indicate that it is explained in section 1.4 Abbreviations or section 1.5 Terminology. All paragraphs from here on in this document are assigned unique tags, composed of a prefix and an identification number for non-ambiguous identification. SDT_REQ X identifies a requirement, and tag SDT_INFO X is used to denote informational text. Whether a requirement refers to client-side or server-side behavior is clear from the context and the requirement text itself. 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]. Details & reviewer feedbackSection 1.3 Document Quirks Page page 4 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. |
The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey. Details & reviewer feedbackSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection; Security evidence and traceability / OEM/Customer Review Interface Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 Page page 16 Feature / Interface Secure communication and freshness protection; Security evidence and traceability / OEM/Customer Review Interface Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”). Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. |
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”). Details & reviewer feedbackSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84). Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 8 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 Page page 13 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: 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. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. |
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. Details & reviewer feedbackSection 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 Page page 16 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At reception of an SDT request, if the security sub-layer is busy, the server shall respond with Details & reviewer feedbackSection 3.3.1 Server’s Behaviour Page page 19 Feature / Interface Secure communication and freshness protection / None Security capability Secure communication Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 3.3.1 Server’s Behaviour Page page 19 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3]. Details & reviewer feedbackSection 3.2.1 HKDF Key Derivation Page page 11 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request. Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response. Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”. Details & reviewer feedbackSection 3.3.1 Server’s Behaviour Page page 18 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
Both client and server shall maintain instances of the state variables PREQARC and PRESARC. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 8 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The server shall populate the SIGLEN protocol element in the request with 16 (0x0010). Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 14 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 14 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The server shall populate the APAR protocol element in the response so that bit 5 is set to true. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 17 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The server shall populate the SIGLEN protocol element in the response with 16 (0x0010). Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 17 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
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. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 1
|
ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state. Details & reviewer feedbackSection 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 Page page 11 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 3.2.1 HKDF Key Derivation Page page 11 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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: 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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: 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Security capability Key management Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”). Details & reviewer feedbackSection 3.3.2 Client’s Behaviour Page page 21 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 4
|
ECUs with diagnostic servers in multiple execution states, e.g. Details & reviewer feedbackSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Figure 6 (new cipher-schemes) Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated Figure 8 (new cipher-schemes) Updated Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Updated 4 References (new cipher-schemes) Updated Annex A (new cipher-schemes) Updated test vectors to be correct after change from SHA-256 to SHA-512 Exhausted PRESARC server behavior. Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
and updated Figure 9.) 2025-08 1 This standard has been revised and is valid for continued use. Details & reviewer feedbackSection (added Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The implementation of SDT (SecuredDataTransmission) shall follow the information provided in Details & reviewer feedbackSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence. Details & reviewer feedbackSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client should populate the ANTIREPLAYCNT protocol element of the first request of an Details & reviewer feedbackSection 3.1 Anti-replay Protection and Transaction Coherency Page page 8 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client shall maintain the state variable PREQTAG. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 9 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 9 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
salt: The salt argument to the HKDF function shall be set as the zero length octet string (null). Details & reviewer feedbackSection 3.2.1 HKDF Key Derivation Page page 11 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The L argument to the HKDF function shall be set to 64. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
𝑁: 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. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM. Details & reviewer feedbackSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / None Security capability Authentication Supplier 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. |
The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: 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. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The L argument to the HKDF function shall be set to 64. Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
𝑁: 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. Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client shall authenticate the SDT request with the 𝐴 argument set to the octet string Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 16 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 16 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 16 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 16 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 16 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
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. Details & reviewer feedbackSection 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 Page page 16 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 17 Feature / Interface Secure communication and freshness protection / External Interfaces Supplier 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. |
At reception of an SDT response, if the client is unauthenticated, the client shall discard the Details & reviewer feedbackSection 3.3.2 Client’s Behaviour Page page 22 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response. Details & reviewer feedbackSection 3.3.2 Client’s Behaviour Page page 22 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard the Details & reviewer feedbackSection 3.3.2 Client’s Behaviour Page page 22 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the Details & reviewer feedbackSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response. Details & reviewer feedbackSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response. Details & reviewer feedbackSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response. Details & reviewer feedbackSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier 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. |
). Details & reviewer feedbackSection If the ANTIREPLAYCNT in a request is less than or equal to PREQARC, the request is rejected ( Page page 8 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
). Details & reviewer feedbackSection If PRESARC is exhausted, the server can no longer respond ( Page page 8 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client may alter the CipherScheme between SDT requests within the same SDT sequence. Details & reviewer feedbackSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
element of the response. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
element of the request. Details & reviewer feedbackSection 3.2.2.2 Server Decryption/Encryption Page page 13 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
𝑃: The 𝑃 (Plaintext) is a zero length octet string (null). Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
𝐶: The 𝐶 (Ciphertext) is a zero length octet string (null). Details & reviewer feedbackSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
element of the response. Details & reviewer feedbackSection That is: 𝐴 ≔ (𝑆𝐷𝑇 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒 − 𝑆𝐼𝐺𝑀𝐴𝐶𝐵𝑌𝑇𝐸)||𝑃𝑅𝐸𝑄𝑇𝐴𝐺 Page page 16 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
element of the request. Details & reviewer feedbackSection 3.2.3.2 Server Verification/Authentication Page page 16 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
. Details & reviewer feedbackSection or • construct a new SDT request, refer to Page page 23 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Added Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Added Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Added Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
(new cipher-schemes) Added Details & reviewer feedbackSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Reads like a requirement but no customer requirement ID was identified in the source. Confirm with the customer before baselining — not counted as a confirmed requirement.
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]. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 1.3 Document Quirks Page page 4 Security capability Key management |
one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. DetailsSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Security capability Diagnostic security Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The User shall apply the latest version of this CVS32. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection page-1 Page 1 Page page 1 |
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”. Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. DetailsSection page-2 Page 2 Page page 2 |
• 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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection page-2 Page 2 Page page 2 |
The server shall respond with application layer NRC 0x39, i.e. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 |
Descriptive or contextual statements with a customer ID but no binding (shall/must) wording.
Target Reader The target readers for this specification are ECU-suppliers and ECU-developers in reference to the server-side requirements, and diagnostic tool developers and back-end service providers regarding the client-side requirements. These “target readers” can be either internal or external in relation to the vehicle manufacturer. DetailsSection 1.3 Document Quirks Page page 4 |
(There may be more than one authentication state). DetailsSection 2 General Page page 6 |
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 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / External Interfaces |
one octet, and the rest should go in the SRVSPECPARAM protocol element. DetailsSection 3.2.2.2 Server Decryption/Encryption Page page 14 Feature / Interface None / External Interfaces |
Although SDT (service 0x84) is of course part of UDS, in this document, SDT is treated much like a transport layer for other UDS services. DetailsSection Figure 1 – SDT Overview Page page 6 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
Figure 1 shows the layout of an SDT message with its protocol elements (for details refer to ISO 14229-1:2020 [1]). DetailsSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
A prerequisite for the SDT service is that a SecuredDataTransmissionKey has been established between client and server using the 0x29 service [6]. DetailsSection 2 General Page page 6 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
The number of concurrently active SDT sequences is limited by the number of authentication states that a server is allowed to maintain, refer to [6]. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None |
This specification defines two counters, one for the request messages and one for responses. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None |
The reason for the two separate counters is that the UDS standard allows for a request to result in multiple responses, e.g. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None |
The state variables needed to keep track of these counters are called PREQARC (Previous REQuest Anti-Replay Counter) and PRESARC (Previous RESponse Anti-Replay Counter). DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 7 Feature / Interface Secure communication and freshness protection / None |
It is good practise to start a sequence with ANTIREPLAYCNT set to zero (0), but this is not something that is enforced by the recipient of the message, be it the first request or response. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 8 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The server handles the exhaustion of PREQARC and PRESARC with its “normal behavior”. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 8 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The requirements above are illustrated in Figure 2. DetailsSection Figure 2 – Anti-replay protection Page page 8 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Apart from ensuring that old messages are not replayed, it is also necessary for the client to be able to determine that an incoming response is actually a response to the request that is currently outstanding. DetailsSection 3.1 Anti-replay Protection and Transaction Coherency Page page 8 Feature / Interface Secure communication and freshness protection / None |
Since any CipherScheme supported by this specification will at least authenticate messages, there will always be a TAG (MAC or similar) populated in the SIGMACBYTE protocol element of all SDT messages. This TAG is used to guarantee request/response coherency and the corresponding state variable is called PREQTAG (Previous REQuest TAG). DetailsSection 3.2 Authenticity and Confidentiality Page page 9 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
The requirements regarding PREQTAG are detailed in sections 3.2.2 and 3.2.3 since they differ slightly between CipherSchemes. DetailsSection 3.2 Authenticity and Confidentiality Page page 9 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
Figure 3 illustrates transaction coherency and the use of PREQTAG. DetailsSection Figure 3 – Anti-replay protection and transaction coherency Page page 9 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
The authenticity, and optionally confidentiality, of an SDT message is provided by the CipherScheme with which the SDT message is authenticated/encrypted. DetailsSection 3.2 Authenticity and Confidentiality Page page 9 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 2
|
The supported CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 [9] are described in sections 3.2.2 and 3.2.3 respectively. The two CipherSchemes require different key material. The Key Derivation Function (KDF) is described in section 3.2.1. DetailsSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None |
Since the two CipherSchemes require different key material, the KDF has to be re-run if the CipherScheme changes. DetailsSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None |
In the following, these state variables are called PSIGENCRYPT (Previous SIGENCRYPT) and PKEY (Previous KEY). DetailsSection 3.2 Authenticity and Confidentiality Page page 10 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Figure 4 illustrates the switching of CipherSchemes within an SDT sequence. The client has previously used CipherScheme 3, and for request X+1, switches to 2. The server reacts on the different SIGENCRYPT and updates its state accordingly. Client Server PREQARC = X DetailsSection 3.2.1 HKDF Key Derivation Page page 11 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Example: “SDT_0x84_KEY” = 5344545F307838345F4B4559 (UTF-8 encoded hex) CipherScheme = 02 (SDT_AEAD_CHACHA20_POLY1305) ➔ info := 5344545F307838345F4B455902 DetailsSection 3.2.1 HKDF Key Derivation Page page 11 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
L: The L argument determines the length of okm and is determined by whichever CipherScheme to be used, see sections 3.2.2 and 3.2.3. DetailsSection 3.2.1 HKDF Key Derivation Page page 11 Feature / Interface Secure communication and freshness protection / None |
okm is the output key material octet string of length L. DetailsSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None |
This section describes a CipherScheme based on AEAD_CHACHA20_POLY1305 [9]. DetailsSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The above requirements are visualized in Figure 5. DetailsSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The plaintext (𝑃) and ciphertext (𝐶) octet strings are of the same length and a concatenation of the INTMSGREQID and SRVSPECPARAM protocol elements. DetailsSection 3.2.2 SDT_AEAD_CHACHA20_POLY1305 Page page 12 Feature / Interface Secure communication and freshness protection / None |
0x84 0x02 xx x X+1 SDT APAR 0x84 0x02 xx x X+1 0xC4 0x02 xxxxxxxxxx x Y+1 0xC4 0x02 xxxxxxxxxx x Y+1 SDTPR APAR RDBI SNOETDID 0 633132 KeyrequestHKDF(ikm, salt, info, 64) -> C TAG || CHACHA20-POLY1305enrypt(Keyrequest, N, A, P)-> CHACHA20-POLY1305decrypt(Keyrequest, N, A, C, TAG)-> S Keyresponse SecuredDataTransmissionKey (ikm) from 0x29 service Client s state variables PREQTAG=TAG_X Server s state variables C 0x22 || Application layer P A || || RDBI0x22 Application layer SNOETDID S C TAG P A CHACHA20-POLY1305enrypt(Keyresponse, N, A, P)-> RDBIPR0x62 0xF19743564320435 64331 SNOETDID Application layer || C TAG S C 6 A || CHACHA20-POLY1305decrypt(Keyresponse, N, A, C, TAG)-> || || RDBIPR SNOETDID 0x62 0xF19743564320435 64331 Application layer S P P ||X+1 N ||X+1 N Y+1 || N ||Y+1 Figure 6 – Example of client and server's behavior using SDT_AEAD_CHACHA20_POLY1305 The example in Figure 6 shows an AEAD_CHACHA20_POLY1305 authenticated and encrypted SDT transaction. DetailsSection 3.2.2.2 Server Decryption/Encryption Page page 14 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The encircled “||” denotes concatenation and the concatenation order is top to bottom in the figure. DetailsSection 3.2.2.2 Server Decryption/Encryption Page page 14 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Encrypted data in the figure is denoted “x..x”, one “x” denotes one encrypted octet. DetailsSection 3.2.2.2 Server Decryption/Encryption Page page 14 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
This section describes a CipherScheme based on the AEAD_CHACHA20_POLY1305 [9] algorithm. Note that in this CipherScheme we only use the authentication properties of AEAD_CHACHA20_POLY1305 i.e., no encryption/decryption. The requirements in this section are visualized with an example in Figure 8. DetailsSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The above requirements are visualized in Figure 7. DetailsSection 3.2.3 SDT_POLY1305 Page page 15 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
0x84 0x03 0x22 X+1 SDT APAR 0x84 0x03 0x22 X+1 0xC4 0x03 0xF1974356432043564331 0x62 Y+1 0xC4 0x03 0xF1974356432043564331 0x62 Y+1 SDTPR APAR 0 633132 KeyrequestHKDF(ikm, salt, info, 64) -> null TAG || CHACHA20-POLY1305authenticate(Keyrequest, N, A, null)-> CHACHA20-POLY1305verify(Keyrequest, N, A, null, TAG)-> ok Keyresponse SecuredDataTransmissionKey (ikm) from 0x29 service Client s state variables PREQTAG=TAG_X Server s state variables A || TAG A CHACHA20-POLY1305authenticate(Keyresponse, N, A, null)-> || null TAG 8 A CHACHA20-POLY1305verify(Keyrequest, N, A, null, TAG)-> ok || TAG A 8 ||X+1 N ||X+1 N ||Y+1 N ||Y+1 N Figure 8 – Example of client and server's behavior using SDT_POLY1305 The example in Figure 8 shows an AEAD_CHACHA20_POLY1305 authenticated SDT transaction. DetailsSection 3.2.3.2 Server Verification/Authentication Page page 17 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The encircled “||” denotes concatenation and the concatenation order is top to bottom relative the symbol. DetailsSection 3.2.3.2 Server Verification/Authentication Page page 17 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
This specification is mainly concerned with errors generated or detected by the client and server’s security sub-layer [1]. General UDS error handling is out of scope of this document. Figure 9 shows how the different “layers”1 interact conceptually. DetailsSection 3.3.1 Server’s Behaviour Page page 18 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
A UDS request/response, in the figure, means any request/response other than SDT (service 0x84). DetailsSection 3.3.1 Server’s Behaviour Page page 18 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
The SDT positive response may of course contain an encapsulated negative UDS response. DetailsSection 3.3.1 Server’s Behaviour Page page 18 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
Figure 10Figure 10 illustrates error- and state handling in the server’s security sub-layer. DetailsSection Figure 9 – Conceptual overview of SDT error handling 3.3.1 Server’s Behaviour Page page 18 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
Note that the markings in the figure, (“S1” through “S3”), and the values for the state variables are correlated with Figure 3. DetailsSection 3.3.1 Server’s Behaviour Page page 18 Feature / Interface Secure communication and freshness protection; Security evidence and traceability / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
For example, APAR dictates encryption, but SIGENCRYPT does not offer encryption. DetailsSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None |
For example, the CipherScheme indicated by SIGENCRYPT produces a TAG of a length different from that indicated by SIGLEN. DetailsSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None |
This means that if the server generates an SDT negative response, the server’s state remains unchanged, i.e. DetailsSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None |
This means that if the server fails to generate an SDT response, the server’s state remains unchanged, i.e. DetailsSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
As mentioned above in this specification, the UDS standard allows for a request to result in multiple responses, e.g. DetailsSection 3.3.1.1 SDT transactions with multiple responses Page page 20 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
Figure 11 shows an example where the client sends a RDBI and the server responds with two instances of RCRRP before delivering the final response. DetailsSection 3.3.2 Client’s Behaviour Page page 21 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
Although this behavior does not alter the requirements put on the server, it is worth to point out that since the server will reuse the TAG received in the request for several responses, the server has to “remember” the TAG from the request. DetailsSection Figure 11 – Example of a multi-response transaction Page page 21 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
Figure 12Figure 12 illustrates error- and state handling in the client’s security sub-layer. DetailsSection 3.3.2 Client’s Behaviour Page page 21 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 4
|
This means that if the client fails to verify/decrypt the SDT response, the client’s state remains unchanged, i.e. DetailsSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None |
Messages can get lost going from client to server, or vice versa. DetailsSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None |
Note that busyRepeatRequest, NRC 0x21 (BRR), can be sent in an SDT negative response, or, encapsulated in an SDT positive response. DetailsSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None |
A negative UDS response BRR encapsulated in a positive SDT response can of course never result in the resending of an old SDT request. DetailsSection 3.3.2.1 Lost and Repeated SDT Messages Page page 23 Feature / Interface Secure communication and freshness protection / None |
DetailsSection Updated Page page 28 Feature / Interface Secure communication and freshness protection / None |
DetailsSection Updated Page page 28 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
DetailsSection Updated Page page 28 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 2
|
DetailsSection Updated Page page 28 Feature / Interface Secure communication and freshness protection / None |
DetailsSection Updated Page page 28 Feature / Interface Secure communication and freshness protection / None |
Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
SDT_AES_SIV_CMAC_256 and SDT_CMAC_128 was deprecated and replaced with SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305. DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
(new cipher-schemes) Updated Table 2 (new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
(new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
(new cipher-schemes) Updated Figure 4 (new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated 3.2.2 heading (new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated Figure 5 annotation (new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 28 Feature / Interface Secure communication and freshness protection / None |
(new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
(new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None |
(new cipher-schemes) Added Figure 7 (new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None |
(new cipher-schemes) Updated DetailsSection 4 Referenced documents and IT-Systems Page page 29 Feature / Interface Secure communication and freshness protection / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 3
|
Definitions, abbreviations, document history, scope and other boilerplate. Not customer requirements.
Document Quirks The purpose of this document is to clarify vehicle manufacturer specific extensions and exceptions to the SecuredDataTransmission 0x84 service specified in ISO14229-1:2020 [1]. This specification does not include any redundant requirements of the normative and indispensable documents referenced below. It contains only clarifications of the requirements and recommendations in these documents together with exceptions and additional requirements that apply to this standard in relation to these documents. The following documents are normative and indispensable for the application of this document: • TRATON Specification on Unified diagnostic Services (UDS) requirements [8] • ISO 14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements [1] DetailsSection 1.3 Document Quirks Page page 4 |
Page 2 Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. DetailsSection page-2 Page 2 Page page 2 |
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-007 | 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 (Interface domain; allocated to External Interfaces; interface: External Interfaces).From this PDF: RFQX-CVS32-0026; RFQX-CVS32-0029; RFQX-CVS32-0030; RFQX-CVS32-0044; RFQX-CVS32-0047; RFQX-CVS32-0071; RFQX-CVS32-0074; RFQX-CVS32-0075; RFQX-CVS32-0076; RFQX-CVS32-0078; RFQX-CVS32-0088; RFQX-CVS32-0100; RFQX-CVS32-0101; RFQX-CVS32-0102; RFQX-CVS32-0104; RFQX-CVS32-0111. | External Interfaces | None | External Interfaces | Supplier-Owned | Candidate | Review + Test + table/diagram context review |
| SSR-COM-009 | 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 (IT / backend domain; allocated to Backend and IT Systems).From this PDF: RFQX-CVS32-0025; RFQX-CVS32-0027; RFQX-CVS32-0028; RFQX-CVS32-0031; RFQX-CVS32-0033; RFQX-CVS32-0048; RFQX-CVS32-0080; RFQX-CVS32-0083; RFQX-CVS32-0084; RFQX-CVS32-0085; RFQX-CVS32-0108; RFQX-CVS32-0109; RFQX-CVS32-0110; RFQX-CVS32-0119; RFQX-CVS32-0121; RFQX-CVS32-0122; RFQX-CVS32-0123; RFQX-CVS32-0124; RFQX-CVS32-0125; RFQX-CVS32-0126; RFQX-CVS32-0128; RFQX-CVS32-0130; RFQX-CVS32-0131; RFQX-CVS32-0147; RFQX-CVS32-0151. | Secure communication and freshness protection | None | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-COM-010 | 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 (System domain; allocated to System Core).From this PDF: RFQX-CVS32-0009; RFQX-CVS32-0012; RFQX-CVS32-0040; RFQX-CVS32-0046; RFQX-CVS32-0053; RFQX-CVS32-0069; RFQX-CVS32-0070; RFQX-CVS32-0077; RFQX-CVS32-0096; RFQX-CVS32-0099; RFQX-CVS32-0103; RFQX-CVS32-0140; RFQX-CVS32-0141; RFQX-CVS32-0142; RFQX-CVS32-0143; RFQX-CVS32-0144; RFQX-CVS32-0145; RFQX-CVS32-0146. | Secure communication and freshness protection | None | None | Supplier-Owned | Candidate | Review + Test + table/diagram context review |
| SSR-COM-011 | 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 (Software domain; allocated to Application Software).From this PDF: RFQX-CVS32-0019; RFQX-CVS32-0058; RFQX-CVS32-0059; RFQX-CVS32-0064; RFQX-CVS32-0091. | Secure communication and freshness protection | None | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-COM-012 | OEM/Customer Review Interface — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS32-0106. | OEM/Customer Review Interface | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-COM-013 | 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 (Cybersecurity domain; allocated to Security Services; security capability: Secure communication).From this PDF: RFQX-CVS32-0120. | Secure communication and freshness protection | Secure communication | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-DAI-009 | 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 (Cybersecurity domain; allocated to Security Services; security capability: Authentication).From this PDF: RFQX-CVS32-0073; RFQX-CVS32-0082; RFQX-CVS32-0092; RFQX-CVS32-0093; RFQX-CVS32-0133; RFQX-CVS32-0139. | Secure communication and freshness protection | Authentication | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-KEY-004 | 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 (Cybersecurity domain; allocated to Security Services; security capability: Key management).From this PDF: RFQX-CVS32-0007; RFQX-CVS32-0051; RFQX-CVS32-0056; RFQX-CVS32-0065; RFQX-CVS32-0066; RFQX-CVS32-0068; RFQX-CVS32-0095. | Secure communication and freshness protection | Key management | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-RBAC-006 | 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 (Software domain; allocated to Application Software).From this PDF: RFQX-CVS32-0057. | Secure communication and freshness protection | None | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| 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 (Cybersecurity domain; allocated to Security Services; security capability: Authentication).From this PDF: RFQX-CVS32-0016. | Secure communication and freshness protection | Authentication | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| 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 (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS32-0054. | Secure communication and freshness protection | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| Impact Area | Evidence From This PDF |
|---|---|
| Impacted system features | Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability |
| Impacted interfaces | External Interfaces; 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; 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/Low; High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Low/Low/Medium; Medium/High/Low; Medium/High/Medium; Medium/Low/Low; Medium/Low/Medium |
| Design assumptions introduced | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation.; Security-relevant requirement the ECU can own once responsibility/method is confirmed. |
| Design decisions required | Confirm with customer whether this is a binding requirement and assign a customer ID.; Agree responsibility split (DIA) for the non-ECU portion. |
| Impact | Status |
|---|---|
| Estimation impact | yes |
| Resource/tool/IT/HW/test impact | High/High/Low; High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Low/Low/Medium; Medium/High/Low; Medium/High/Medium; Medium/Low/Low; Medium/Low/Medium |
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: Secure communication and freshness protection"]
doc --> f0
f1["Feature: Secure communication and freshness protection; Security evidence and traceability"]
doc --> f1
i0["Interface: External Interfaces"]
doc --> i0
i1["Interface: OEM/Customer Review Interface"]
doc --> i1
s0["SSR: SSR-COM-007"]
doc --> s0
s1["SSR: SSR-COM-009"]
doc --> s1
s2["SSR: SSR-COM-010"]
doc --> s2
o0["Open point: OP-002"]
doc --> o0
o1["Open point: OP-004"]
doc --> o1
o2["Open point: OP-005"]
doc --> o2
CVS32.pdf
Data Security Container / Secure Data Transfer Standard
Secure Data Transfer
121 requirements, 74 information, 11 SSRs
2 tables, 20 diagrams
Markdown-derived requirements and registers; OCR disabled; no downstream PDF analysis
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Customer Requirement | SSR | Disposition | Confidence | Reason |
|---|---|---|---|---|
| RFQX-CVS32-0001 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS32-0002 | None | Covered by Existing Supplier System Requirement | n/a | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0003 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS32-0004 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS32-0005 | None | Covered by Existing Supplier System Requirement | n/a | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0006 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0007 | SSR-KEY-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0008 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS32-0009 | SSR-COM-010 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS32-0010 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0011 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0012 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0013 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0014 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS32-0015 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0016 | SSR-RBAC-007 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0017 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0018 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0019 | SSR-COM-011 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0020 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS32-0021 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0022 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0023 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0024 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0025 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0026 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0027 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0028 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0029 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0030 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0031 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0032 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0033 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0034 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0035 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0036 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0037 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0038 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0039 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0040 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0041 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0042 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0043 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0044 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0045 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0046 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0047 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0048 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0049 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0050 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0051 | SSR-KEY-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0052 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0053 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0054 | SSR-VV-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0055 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0056 | SSR-KEY-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0057 | SSR-RBAC-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0058 | SSR-COM-011 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0059 | SSR-COM-011 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0060 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0061 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0062 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0063 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0064 | SSR-COM-011 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0065 | SSR-KEY-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0066 | SSR-KEY-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0067 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0068 | SSR-KEY-004 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0069 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0070 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0071 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0072 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0073 | SSR-DAI-009 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS32-0074 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0075 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0076 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0077 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0078 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0079 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0080 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0081 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0082 | SSR-DAI-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0083 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0084 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0085 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0086 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0087 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0088 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0089 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0090 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0091 | SSR-COM-011 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0092 | SSR-DAI-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0093 | SSR-DAI-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0094 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0095 | SSR-KEY-004 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0096 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0097 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0098 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0099 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0100 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0101 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0102 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0103 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0104 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0105 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0106 | SSR-COM-012 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0107 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0108 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0109 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0110 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0111 | SSR-COM-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0112 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0113 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0114 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0115 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0116 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0117 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0118 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0119 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0120 | SSR-COM-013 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0121 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0122 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0123 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0124 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0125 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0126 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0127 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0128 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0129 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0130 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0131 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0132 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0133 | SSR-DAI-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0134 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0135 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0136 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0137 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0138 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0139 | SSR-DAI-009 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0140 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0141 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0142 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0143 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0144 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0145 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0146 | SSR-COM-010 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS32-0147 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0148 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0149 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0150 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0151 | SSR-COM-009 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS32-0152 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0153 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0154 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0155 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0156 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0157 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0158 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0159 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0160 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0161 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0162 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0163 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0164 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0165 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0166 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0167 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0168 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0169 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0170 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0171 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0172 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0173 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0174 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0175 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0176 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0177 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0178 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0179 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0180 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0181 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0182 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0183 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0184 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0185 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0186 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0187 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0188 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0189 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0190 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0191 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0192 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0193 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0194 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0195 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0196 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0197 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0198 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0199 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0200 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0201 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0202 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS32-0203 | None | Informational Only | n/a | Non-binding; not derived. |
CVS32.pdfconverted/markdown/source documentScope: this data security container / secure data transfer standard specifies secure communication and freshness protection, covering 1 Introduction; 1.3 Document Quirks; 2 General; 3 ISO 14299-1:2020 Clarifications and Deviations; 3.1 Anti-replay Protection and Transaction Coherency; 3.2 Authenticity and Confidentiality. System boundary and interfaces: the document constrains 1 interface(s) - OEM/Customer Review Interface; principal functions in scope are Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability.
Engineering obligations: 121 confirmed customer requirement(s) carry an explicit ID and normative wording and must be implemented and verified; 6 further requirement-like statement(s) have no customer ID and must be clarified before they can be baselined; 74 informational and 2 reference item(s) were separated out as non-binding. Design and security impact: affects Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability; security capabilities touched: Key management; Diagnostic security; Authentication; Secure communication; 11 supplier system requirement(s) were derived from this document.
Open for the customer: 5 document-linked open point(s) - mainly Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. (sample: 3 of 5) - plus 6 unidentified requirement-like statement(s). Do not baseline these until the customer confirms. Confidence and limits: High confidence. Categorisation is derived from the converted Markdown (customer IDs, normative wording, and section context); no OCR or downstream PDF analysis is used.
| Field | Interpretation |
|---|---|
| Document Purpose | Scope: this data security container / secure data transfer standard specifies secure communication and freshness protection, covering 1 Introduction; 1.3 Document Quirks; 2 General; 3 ISO 14299-1:2020 Clarifications and Deviations; 3.1 Anti-replay Protection and Transaction Coherency; 3.2 Authenticity and Confidentiality. |
| Engineering Interpretation | System boundary and interfaces: the document constrains 1 interface(s) - OEM/Customer Review Interface; principal functions in scope are Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability. |
| Supplier Proposal Impact | Engineering obligations: 121 confirmed customer requirement(s) carry an explicit ID and normative wording and must be implemented and verified; 6 further requirement-like statement(s) have no customer ID and must be clarified before they can be baselined; 74 informational and 2 reference item(s) were separated out as non-binding. |
| System / Security Impact | Design and security impact: affects Secure communication and freshness protection; Secure communication and freshness protection; Security evidence and traceability; security capabilities touched: Key management; Diagnostic security; Authentication; Secure communication; 11 supplier system requirement(s) were derived from this document. |
| Customer Clarification Impact | Open for the customer: 5 document-linked open point(s) - mainly Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. (sample: 3 of 5) - plus 6 unidentified requirement-like statement(s). Do not baseline these until the customer confirms. |
| Confidence and Limits | Confidence and limits: High confidence. Categorisation is derived from the converted Markdown (customer IDs, normative wording, and section context); no OCR or downstream PDF analysis is used. |
| Theme | Summary | Requirement Count | Representative Requirements |
|---|---|---|---|
| Secure communication and freshness protection | Defines protected communication behavior, freshness/replay checks, and signal or PDU allocation dependencies. | 193 | RFQX-CVS32-0007; RFQX-CVS32-0009; RFQX-CVS32-0010 |
| System architecture design | Groups related document requirements into a single engineering theme. | 135 | RFQX-CVS32-0001; RFQX-CVS32-0002; RFQX-CVS32-0009 |
| Requirement | Groups related document requirements into a single engineering theme. | 121 | RFQX-CVS32-0007; RFQX-CVS32-0009; RFQX-CVS32-0012 |
| System | Groups related document requirements into a single engineering theme. | 100 | RFQX-CVS32-0001; RFQX-CVS32-0002; RFQX-CVS32-0009 |
| Information | Groups related document requirements into a single engineering theme. | 74 | RFQX-CVS32-0006; RFQX-CVS32-0010; RFQX-CVS32-0011 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 69 | RFQX-CVS32-0003; RFQX-CVS32-0004; RFQX-CVS32-0005 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 46 | RFQX-CVS32-0003; RFQX-CVS32-0004; RFQX-CVS32-0005 |
| Cybersecurity | Groups related document requirements into a single engineering theme. | 27 | RFQX-CVS32-0005; RFQX-CVS32-0006; RFQX-CVS32-0007 |
| Section | Requirements | Information | Unknown | Excluded | Total Items | Critical | Open Points | SSR Links |
|---|---|---|---|---|---|---|---|---|
| 1 Introduction | 1 | 1 | 0 | 0 | 4 | 2 | 2 | 1 |
| -- 1.3 Document Quirks | 1 | 1 | 0 | 0 | 4 | 2 | 2 | 1 |
| 2 General | 4 | 4 | 0 | 0 | 9 | 2 | 1 | 2 |
| 3 ISO 14299-1:2020 Clarifications and Deviations | 87 | 48 | 0 | 0 | 136 | 38 | 2 | 10 |
| -- 3.1 Anti-replay Protection and Transaction Coherency | 11 | 9 | 0 | 0 | 21 | 7 | 2 | 3 |
| -- 3.2 Authenticity and Confidentiality | 53 | 22 | 0 | 0 | 75 | 17 | 1 | 9 |
| -- -- 3.2.1 HKDF Key Derivation | 4 | 3 | 0 | 0 | 7 | 1 | 0 | 3 |
| -- -- 3.2.2 SDT_AEAD_CHACHA20_POLY1305 | 20 | 8 | 0 | 0 | 28 | 7 | 1 | 6 |
| -- -- -- 3.2.2.2 Server Decryption/Encryption | 13 | 4 | 0 | 0 | 17 | 5 | 1 | 4 |
| -- -- 3.2.3 SDT_POLY1305 | 20 | 4 | 0 | 0 | 24 | 6 | 1 | 7 |
| -- -- -- 3.2.3.2 Server Verification/Authentication | 13 | 2 | 0 | 0 | 15 | 4 | 1 | 4 |
| -- 3.3 Error- and state-handling | 23 | 17 | 0 | 0 | 40 | 14 | 1 | 4 |
| -- -- 3.3.1 Server’s Behaviour | 12 | 10 | 0 | 0 | 22 | 12 | 1 | 3 |
| -- -- -- 3.3.1.1 SDT transactions with multiple responses | 9 | 5 | 0 | 0 | 14 | 9 | 1 | 2 |
| -- -- 3.3.2 Client’s Behaviour | 11 | 7 | 0 | 0 | 18 | 2 | 1 | 3 |
| -- -- -- 3.3.2.1 Lost and Repeated SDT Messages | 7 | 4 | 0 | 0 | 11 | 2 | 1 | 2 |
| 4 Referenced documents and IT-Systems | 29 | 21 | 0 | 0 | 50 | 0 | 0 | 0 |
| Artifact | Type | Caption | Page | Related Requirements | Impact |
|---|---|---|---|---|---|
| TABLE-CVS32-0001 | Table | Table 1 – Abbreviations | page 5 | None | Security protocol or cryptographic context |
| TABLE-CVS32-0002 | Table | Table 2 – Supported CipherSchemes | page 10 | RFQX-CVS32-0043; RFQX-CVS32-0051; RFQX-CVS32-0053; RFQX-CVS32-0054; RFQX-CVS32-0047; RFQX-CVS32-0048; RFQX-CVS32-0049; RFQX-CVS32-0052 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0001 | Diagram | Figure 1 – SDT Overview | page 6 | RFQX-CVS32-0010; RFQX-CVS32-0009; RFQX-CVS32-0011; RFQX-CVS32-0015; RFQX-CVS32-0012; RFQX-CVS32-0013 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0002 | Diagram | Figure 1 shows the layout of an SDT message with its protocol elements (for details refer to | page 6 | RFQX-CVS32-0011; RFQX-CVS32-0010; RFQX-CVS32-0009; RFQX-CVS32-0015; RFQX-CVS32-0016; RFQX-CVS32-0012; RFQX-CVS32-0013; RFQX-CVS32-0014 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0003 | Diagram | Figure 2 – Anti-replay protection | page 8 | RFQX-CVS32-0031; RFQX-CVS32-0033; RFQX-CVS32-0030; RFQX-CVS32-0032; RFQX-CVS32-0034; RFQX-CVS32-0035; RFQX-CVS32-0036; RFQX-CVS32-0037 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0004 | Diagram | Figure 3 – Anti-replay protection and transaction coherency | page 9 | RFQX-CVS32-0039; RFQX-CVS32-0043; RFQX-CVS32-0044; RFQX-CVS32-0040; RFQX-CVS32-0041; RFQX-CVS32-0042; RFQX-CVS32-0155; RFQX-CVS32-0156 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0005 | Diagram | Figure 3 illustrates transaction coherency and the use of PREQTAG. To avoid mix-up, the | page 9 | RFQX-CVS32-0039; RFQX-CVS32-0043; RFQX-CVS32-0044; RFQX-CVS32-0040; RFQX-CVS32-0041; RFQX-CVS32-0042; RFQX-CVS32-0155; RFQX-CVS32-0156 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0006 | Diagram | Figure 4 illustrates the switching of CipherSchemes within an SDT sequence. The client has | page 11 | RFQX-CVS32-0055; RFQX-CVS32-0053; RFQX-CVS32-0054; RFQX-CVS32-0169 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0007 | Diagram | Figure 4 – Change of CipherScheme mid sequence | page 11 | RFQX-CVS32-0056; RFQX-CVS32-0057; RFQX-CVS32-0058; RFQX-CVS32-0059; RFQX-CVS32-0060; RFQX-CVS32-0170 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0008 | Diagram | Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 | page 12 | RFQX-CVS32-0068; RFQX-CVS32-0063; RFQX-CVS32-0064; RFQX-CVS32-0065; RFQX-CVS32-0066; RFQX-CVS32-0067; RFQX-CVS32-0069; RFQX-CVS32-0070 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0009 | Diagram | Figure 6 – Example of client and server's behavior using SDT_AEAD_CHACHA20_POLY1305 | page 14 | RFQX-CVS32-0086; RFQX-CVS32-0087; RFQX-CVS32-0089; RFQX-CVS32-0182; RFQX-CVS32-0080 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0010 | Diagram | Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 | page 15 | RFQX-CVS32-0095; RFQX-CVS32-0090; RFQX-CVS32-0091; RFQX-CVS32-0092; RFQX-CVS32-0093; RFQX-CVS32-0094; RFQX-CVS32-0096; RFQX-CVS32-0097 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0011 | Diagram | Figure 8 – Example of client and server's behavior using SDT_POLY1305 | page 17 | RFQX-CVS32-0112; RFQX-CVS32-0113; RFQX-CVS32-0106 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0012 | Diagram | Figure 9 shows how the different “layers”1 interact conceptually. | page 18 | RFQX-CVS32-0114; RFQX-CVS32-0115; RFQX-CVS32-0117; RFQX-CVS32-0118; RFQX-CVS32-0113; RFQX-CVS32-0201; RFQX-CVS32-0116 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0013 | Diagram | Figure 9 – Conceptual overview of SDT error handling | page 18 | RFQX-CVS32-0115; RFQX-CVS32-0119; RFQX-CVS32-0114; RFQX-CVS32-0117; RFQX-CVS32-0118; RFQX-CVS32-0201; RFQX-CVS32-0116 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0014 | Diagram | Figure 10Figure 10 illustrates error- and state handling in the server’s security sub-layer. The | page 18 | RFQX-CVS32-0119; RFQX-CVS32-0115; RFQX-CVS32-0114; RFQX-CVS32-0117; RFQX-CVS32-0118; RFQX-CVS32-0201; RFQX-CVS32-0116 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS32-0015 | Diagram | Figure 10 – Server's error and state handling | page 19 | RFQX-CVS32-0121; RFQX-CVS32-0120; RFQX-CVS32-0119; RFQX-CVS32-0122 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0016 | Diagram | Figure 11 shows an example where the client sends a RDBI and the server responds with two | page 21 | RFQX-CVS32-0136; RFQX-CVS32-0135; RFQX-CVS32-0138; RFQX-CVS32-0139; RFQX-CVS32-0137; RFQX-CVS32-0134 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0017 | Diagram | Figure 11 – Example of a multi-response transaction | page 21 | RFQX-CVS32-0135; RFQX-CVS32-0139; RFQX-CVS32-0138; RFQX-CVS32-0136; RFQX-CVS32-0137 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0018 | Diagram | Figure 12Figure 12 illustrates error- and state handling in the client’s security sub-layer. The | page 21 | RFQX-CVS32-0138; RFQX-CVS32-0139; RFQX-CVS32-0136; RFQX-CVS32-0137 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0019 | Diagram | Figure 12 – The client's error and state handling | page 22 | RFQX-CVS32-0140; RFQX-CVS32-0141; RFQX-CVS32-0142; RFQX-CVS32-0139; RFQX-CVS32-0143; RFQX-CVS32-0138 | Security protocol or cryptographic context |
| DIAGRAM-CVS32-0020 | Diagram | Figure 9.) | page 29 | RFQX-CVS32-0203; RFQX-CVS32-0190; RFQX-CVS32-0191; RFQX-CVS32-0192; RFQX-CVS32-0193; RFQX-CVS32-0194; RFQX-CVS32-0195; RFQX-CVS32-0196 | Security protocol or cryptographic context |
Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed.
| ID | Score | Category | Reason | Statement |
|---|---|---|---|---|
| RFQX-CVS32-0008 | 95 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | 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]. |
| RFQX-CVS32-0014 | 95 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. |
| RFQX-CVS32-0007 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | The mnemonics defined in the ISO14229-1:2020 [1] standard are reused throughout this document. Some paragraphs in this document includes pseudo code. The pseudo code make use of the following notation: 𝑋 // 𝑌 The concatenation of the octet strings 𝑋 and 𝑌 𝑋𝑠𝑒𝑟𝑣𝑒𝑟 𝑋 is owned by the Server 𝑋𝑐𝑙𝑖𝑒𝑛𝑡 𝑋 is owned by the Client The first occurrence of an abbreviation or term in this document will appear italicized to indicate that it is explained in section 1.4 Abbreviations or section 1.5 Terminology. All paragraphs from here on in this document are assigned unique tags, composed of a prefix and an identification number for non-ambiguous identification. SDT_REQ X identifies a requirement, and tag SDT_INFO X is used to denote informational text. Whether a requirement refers to client-side or server-side behavior is clear from the context and the requirement text itself. 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]. |
| RFQX-CVS32-0016 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey. |
| RFQX-CVS32-0027 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| RFQX-CVS32-0051 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. |
| RFQX-CVS32-0054 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| RFQX-CVS32-0106 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| RFQX-CVS32-0131 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| RFQX-CVS32-0133 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”). |
| 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-004 | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Update-control scope and evidence ownership stay open; risk of an unprotected update path. | 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 | |
| OP-009 | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case. | Open | |
| OP-011 | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. | Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Open |
| SSR | Title | Statement | Reqs From This PDF | Other PDFs | Status |
|---|---|---|---|---|---|
| SSR-COM-007 | 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 (Interface domain; allocated to External Interfaces; interface: External Interfaces). | RFQX-CVS32-0026; RFQX-CVS32-0029; RFQX-CVS32-0030; RFQX-CVS32-0044; RFQX-CVS32-0047; RFQX-CVS32-0071; RFQX-CVS32-0074; RFQX-CVS32-0075; RFQX-CVS32-0076; RFQX-CVS32-0078; RFQX-CVS32-0088; RFQX-CVS32-0100; RFQX-CVS32-0101; RFQX-CVS32-0102; RFQX-CVS32-0104; RFQX-CVS32-0111 | no | Candidate |
| SSR-COM-009 | 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 (IT / backend domain; allocated to Backend and IT Systems). | RFQX-CVS32-0025; RFQX-CVS32-0027; RFQX-CVS32-0028; RFQX-CVS32-0031; RFQX-CVS32-0033; RFQX-CVS32-0048; RFQX-CVS32-0080; RFQX-CVS32-0083; RFQX-CVS32-0084; RFQX-CVS32-0085; RFQX-CVS32-0108; RFQX-CVS32-0109; RFQX-CVS32-0110; RFQX-CVS32-0119; RFQX-CVS32-0121; RFQX-CVS32-0122; RFQX-CVS32-0123; RFQX-CVS32-0124; RFQX-CVS32-0125; RFQX-CVS32-0126; RFQX-CVS32-0128; RFQX-CVS32-0130; RFQX-CVS32-0131; RFQX-CVS32-0147; RFQX-CVS32-0151 | no | Blocked by Customer Clarification |
| SSR-COM-010 | 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 (System domain; allocated to System Core). | RFQX-CVS32-0009; RFQX-CVS32-0012; RFQX-CVS32-0040; RFQX-CVS32-0046; RFQX-CVS32-0053; RFQX-CVS32-0069; RFQX-CVS32-0070; RFQX-CVS32-0077; RFQX-CVS32-0096; RFQX-CVS32-0099; RFQX-CVS32-0103; RFQX-CVS32-0140; RFQX-CVS32-0141; RFQX-CVS32-0142; RFQX-CVS32-0143; RFQX-CVS32-0144; RFQX-CVS32-0145; RFQX-CVS32-0146 | no | Candidate |
| SSR-COM-011 | 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 (Software domain; allocated to Application Software). | RFQX-CVS32-0019; RFQX-CVS32-0058; RFQX-CVS32-0059; RFQX-CVS32-0064; RFQX-CVS32-0091 | no | Blocked by Customer Clarification |
| SSR-COM-012 | OEM/Customer Review Interface — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface). | RFQX-CVS32-0106 | no | Blocked by Customer Clarification |
| SSR-COM-013 | 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 (Cybersecurity domain; allocated to Security Services; security capability: Secure communication). | RFQX-CVS32-0120 | no | Blocked by Customer Clarification |
| SSR-DAI-009 | 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 (Cybersecurity domain; allocated to Security Services; security capability: Authentication). | RFQX-CVS32-0073; RFQX-CVS32-0082; RFQX-CVS32-0092; RFQX-CVS32-0093; RFQX-CVS32-0133; RFQX-CVS32-0139 | no | Blocked by Customer Clarification |
| SSR-KEY-004 | 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 (Cybersecurity domain; allocated to Security Services; security capability: Key management). | RFQX-CVS32-0007; RFQX-CVS32-0051; RFQX-CVS32-0056; RFQX-CVS32-0065; RFQX-CVS32-0066; RFQX-CVS32-0068; RFQX-CVS32-0095 | no | Blocked by Customer Clarification |
| SSR-RBAC-006 | 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 (Software domain; allocated to Application Software). | RFQX-CVS32-0057 | no | 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 (Cybersecurity domain; allocated to Security Services; security capability: Authentication). | RFQX-CVS32-0016 | no | Blocked by Customer Clarification |
| 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 (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface). | RFQX-CVS32-0054 | no | Blocked by Customer Clarification |