SNIP_CLASSIC_SECOC_SECTION_7_5_Verification_of_incoming_PDUs

7.5 Verification of incoming PDUs The term verification describes the process of comparing the Authentication Information contained in a Secured I-PDU with the Authentication Information calculated on basis of the local Data Identifier, the local Freshness Value and the Authentic I-PDU contained in the Secured I-PDU. The process of verifying incoming Secured I-PDUs is described in general terms in Section 7.1.3. 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. The overall interaction with the PduR module and the verification of Secured I-PDUs is organized as described in the following scheme: 1. For each indication of an incoming Secured I-PDU from a lower layer bus interface or transport protocol module, the SecOC module takes the role of an upper layer communication module and thus serves all lower layer requests that are necessary to receive the complete Secured I-PDU. 2. The SecOC module copies the Secured I-PDU into its own memory. 3. Thereafter, when the complete Secured I-PDU is available and during the next scheduled call of its main function, the SecOC module verifies the contents of the Secured I-PDU according to SWS_SecOC_00040. 4. If the verification fails and the parameter SecOCIgnoreVerificationResult is configured to FALSE, the SecOC module drops the Secured I-PDU. 5. If the verification succeeds or the verification fails and the parameter SecOCIgnoreVerificationResult is configured to TRUE, the SecOC module takes the role of a lower layer communication module and calls PduR_SecOC[If|Tp]RxIndication for the Authentic I-PDU. 6. The SecOC reports the verification results according to SWS_SecOC_00048. Thus, SecOC decouples the interaction between upper layer modules and lower layer modules. The SecOC module manages the interaction with lower layer module until it has copied the complete Secured I-PDU into its own buffer. It does so without affecting the upper layer module. Thereafter, it verifies the contents of the Secured I-PDU and, dependent on the verification results, initiates the transmission of the Authentic I-PDU to the upper layer communication module. [SWS_SecOC_00214]⌈ In case the SecOCReceptionOverflowStrategy is set to REPLACE, the SecOC module shall free all buffer related to a Secured I-PDU if the reception of a Secured I-PDU with the same Pdu Identifier has been initiated. ⌋(SRS_SecOC_00021, SRS_SecOC_00022) [SWS_SecOC_00215]⌈ In case the SecOCReceptionOverflowStrategy is set to REJECT and SecOC is currently busy with the same Secured I-PDU, the SecOC module shall ignore any subsequent call of SecOC_RxIndication and return BUFREQ_E_NOT_OK for any subsequent call of SecOC_StartOfReception. ⌋(SRS_SecOC_00021, SRS_SecOC_00022) [SWS_SecOC_00204]⌈ SecOC shall provide separate buffers for the incoming Secured I-PDU, Cryptographic I-PDU and the resulting Authentic I-PDU. ⌋(SRS_SecOC_00026) Note: Thus, lower layer updates of Secured I-PDUs could be processed without affecting ongoing deliveries of an Authentic I-PDU to the upper layer communication modules. [SWS_SecOC_00216]⌈ In case the SecOCReceptionOverflowStrategy is set to QUEUE and SecOC is currently busy with the same Secured I-PDU, the SecOC module shall additionally receive the Secured I-PDU and queue them for a subsequent processing after the currently processed Secured I-PDU is finalized. In case the limit which is given by SecOCReceptionQueueSize is reach any further reception shall be rejected. ⌋(SRS_SecOC_00021, SRS_SecOC_00022) [SWS_SecOC_00205]⌈ For each Secured I-PDU having SecOCRxSecuredPduCollection present in the corresponding SecOCRxSecuredPduLayer SecOC shall buffer only the last Authentic I-PDU and Cryptographic I-PDU it has received. If a buffer has already been filled with a previous I-PDU, the previous I-PDU is overwritten. ⌋(SRS_SecOC_00026) Note: An Authentic I-PDU and its corresponding Cryptographic I-PDU must be received in direct succession but their order does not matter. This can be realized for example via priority handling dependent on the underlying bus system. [SWS_SecOC_00206]⌈ SecOC shall construct and the Secured I-PDU immediately after it has received both the respective Authentic I-PDU and Cryptographic I-PDU. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are handled according to overrideStatus value. ⌋(SRS_SecOC_00026) [SWS_SecOC_00207]⌈ If the subsequent verification of the resulting Secured I-PDU is successful, then SecOC shall clear the buffers of both the Authentic and Cryptographic I-PDU. ⌋(SRS_SecOC_00026) [SWS_SecOC_00257]⌈ For a Secured Rx I-PDU with SecOCAuthPduHeaderLength = 0 or not configured and SecOCDynamicRuntimeLengthHandling set to FALSE, the SecOC module shall extract the Authentic I-PDU by using the configured length of the corresponding global PDU. ⌋() [SWS_SecOC_00258]⌈ For a Secured Rx I-PDU with SecOCAuthPduHeaderLength = 0 or not configured and SecOCDynamicRuntimeLengthHandling set to TRUE, the SecOC module shall extract the Authentic I-PDU by using the length provided by the lower layer. ⌋() [SWS_SecOC_00259]⌈ For a Secured Rx I-PDU with SecOCAuthPduHeaderLength > 0, the SecOC module shall extract the Authentic I-PDU using the length provided at runtime within the Secured I-PDU Header. ⌋()