SNIP_CLASSIC_SECOC_SECTION_7_4_Authentication_of_outgoing_PDUs

7.4 Authentication of outgoing PDUs The term authentication describes the creation of a Secured I-PDU by adding Authentication Information to an Authentic I-PDU. This process is described in general terms in Section 7.1.2. This section refines the general description with respect to requirements arising from the integration with the PduR module considering different bus interfaces and transport protocols. In general, the interaction with the PduR module and the authentication of Authentic I-PDUs are organized according to the following scheme: 1. For each transmission request of an Authentic I-PDU, the upper layer communication module shall call the PduR module through PduR_<Up>Transmit. 2. The PduR routes this request to the SecOC module and calls SecOC_[If|Tp]Transmit. 3. The SecOC module copies the Authentic I-PDU to its own memory and returns. 4. During the next scheduled call of its main function, the SecOC module creates the Secured I-PDU by calculating the Authentication Information and initiates the transmission of the Secured I-PDU by notifying the respective lower layer module via the PduR module. 5. Thereafter, the SecOC module takes the role of an upper layer communication module and thus serves all lower layer requests to provide information on or to copy data of the Secured I-PDU. 6. Finally, the confirmation of the successful or unsuccessful transmission of the Secured I-PDU are provided to the upper layer communication module as confirmation of the successful or unsuccessful transmission of the Authentic I-PDU Note: For each Authentic I-PDU, the upper layer communication module shall be configured in such a way that it calls the PduR module as it normally does for a direct transmission request. In this case, the upper layer is decoupled from TriggerTransmit and TP behavior by means of the SecOC module. To initiate the transmission of an Authentic I-PDU, the upper layer module always (and independent of the bus interface that is used for the concrete transmission) calls the PduR module through PduR_<Up>Transmit. The PduR routes this request to the SecOC module so that the SecOC module has immediate access to the Authentic I-PDU in the buffer of the upper layer communication module. [SWS_SecOC_00252]⌈ The SecOC module shall copy the complete Authentic I-PDU to its internal memory before starting transmission of the corresponding Secured I-PDU. ⌋ (SRS_SecOC_00032) Note: This means there is no dependency between the IF/TP configuration of Up versus Lower PDU interfaces. [SWS_SecOC_00201]⌈ If SecOCTxSecuredPduCollection is used, then SecOC shall transmit the Secured I-PDU as two messages: The original Authentic I-PDU and a separate Cryptographic I-PDU. The Cryptographic I-PDU shall contain all Authentication Information of the Secured I-PDU, so that the Authentic I-PDU and the Cryptographic I-PDU contain all information necessary to reconstruct the Secured I-PDU. ⌋(SRS_SecOC_00026) Note: This applies to all instances when a Secured I-PDU is transmitted by SecOC to the PduR. There is no further distinction made throughout this document to avoid duplication and clutter. [SWS_SecOC_00202]⌈ SecOC shall transmit an Authentic I-PDU and its corresponding Cryptographic I-PDU within the same main function cycle. ⌋(SRS_SecOC_00026) [SWS_SecOC_00209]⌈ If SecOCTxSecuredPduCollection is used then SecOC shall repeat a part of the Authentic I-PDU inside the Cryptographic I-PDU as Message Linker and the Cryptographic I-PDU shall be constructed as Cryptographic I-PDU =Authentication Data | Message Linker ⌋(SRS_SecOC_00028) Note: “|” denotes concatenation. [SWS_SecOC_00210]⌈ If SecOCUseMessageLink is used then SecOC shall use the value at bit position SecOCMessageLinkPos of length SecOCMessageLinkLen bits inside the Authentic I-PDU as the Message Linker. ⌋(SRS_SecOC_00028) [SWS_SecOC_00270]⌈ If SecOCTxSecuredPduCollection is used, the SecOC shall forward the TxConfirmation to the upper layer if the SecOC_TxConfirmation was called for the Authentic I-PDU and the Cryptographic I-PDU. The reult parameter of the upper layer TxConfirmation call shall only be E_OK if the result parameters for both TxConfirmation calls were E_OK, Otherwise the result parameter shall be E_NOT_OK. ⌋() [SWS_SecOC_00057]⌈ The SecOC module shall provide sufficient buffer capacities to store the incoming Authentic I-PDU, the outgoing Secured I-PDU and all intermediate data of the authentication process according to the process described in SWS_SecOC_00031. ⌋(SRS_SecOC_00006) [SWS_SecOC_00146]⌈ The SecOC module shall provide separate buffers for the Authentic I-PDU and the Secured I-PDU. ⌋(SRS_SecOC_00006) [SWS_SecOC_00110]⌈ Any transmission request from the upper layer communication module shall overwrite the buffer that contains the Authentic I-PDU without affecting the buffer of the respective Secured I-PDU. ⌋(SRS_BSW_00426) Thus, upper layer updates for Authentic I-PDUs could be processed without affecting ongoing transmission activities of Secured I-PDUs with the lower layer communication module. [SWS_SecOC_00262]⌈ For a Tx Secured I-PDU with SecOCAuthPduHeaderLength > 0, the SecOC module shall add the Secured I-PDU Header to the Secured I-PDU with the length of the Authentic I-PDU within the Secured I-PDU, to handle dynamic Authentic I-PDU. Note: Primary purpose of this Header is to indicate the position of Freshness Value and Authenticator in Secured I-PDUs with dynamic length Authentic I-PDU.Also some buses which cannot select arbitrary length of L-PDU (e.g. CAN FD and FlexRay) require this Header, because the position of Freshness Value and Authenticator is not always at the end of the Secured I-PDU, as lower layer modules (e.g. CanIf and FrIf) may add bus-specific padding bytes after processing at SecOC (then the L-PDU containing the Secured I-PDU with padding will be: Secured I-PDU = Secured I-PDU Header | Authentic I-PDU | Freshness Value | Authenticator | Bus-specific padding). ⌋(SRS_SecOC_00006)