This specification is a software specification for the vehicle safety communication (SecOC) module. It is based on AUTOSAR SecOC and specifies how to implement the requirements from AUTOSAR SecOC SRS. It describes the basic security features, functions and APIs of the automatic sarSecOC module.

The SecOC module aims to provide resource-efficient and practical authentication mechanisms for critical data at the PDU level. The authentication mechanism should be seamlessly integrated with the current AUTOSAR communication system. The impact on resource consumption should be as small as possible to provide additional protection for legacy systems. The specification is based on the assumption of primarily using symmetric authentication methods with message authentication codes (MACs). They achieve the same level of security using smaller keys than asymmetric methods and can be implemented compactly and efficiently in software and hardware. However, the specification provides the necessary level of abstraction so that both symmetric and asymmetric authentication methods can be used at the same time.

The SecOC module is integrated on the basis of AUTOSAR PduR. In this setup, PduR is responsible for routing incoming and outgoing security-related ipdus to the SecOC module. The SecOC module shall then add or process the security related information and shall propagate the result back to the PduR in the form of an I-PDU. The PduR will then be responsible for further routing of the i-pdu. In addition, the SecOC module utilizes the cryptographic services provided by the CSM and interacts with Rte to allow key and counter management. The SecOC module shall support all types of communication paradigms and principles supported by PduR, especially multicast communication, transport protocols and PduR gateways. The following sections provide a detailed description of the SecOC interface, functionality, and configuration.

2. Constraints and Assumptions

The SecOC module is used in all ecu's that require secure communication.

The SecOC module can only be used to protect an entire SomeIpTp message, not a single segment of a SomeIpTp message.

3. Dependent modules

(1) PduR: The SecOC module depends on the API and functions of PduR. It provides the upper and lower API functions required by the PDU router;

(2) CSM: The SecOC module depends on the encryption algorithm provided by the CSM module. The SecOC module requires API functions to generate and verify cryptographic signatures or message authentication codes;

(3) The SecOC module provides an API with management functions. This API contains the following API functions provided by RTE as service interfaces.

SecOC_VerificationStatus
SecOC_VerifyStatusOverride.
SecOC_VerificationStatusIndication

4. Function description

The goal of the SecOC module is to implement a resource-efficient and practical authentication mechanism for sensitive data at the PDU level. The methods proposed in this specification generally support the use of symmetric and asymmetric methods for authenticity and integrity protection. Both approaches broadly aim at the same goal and show major similarities conceptually, but also some differences due to different technical properties of the underlying primitives. Also, the common terminology for using authenticators is different. In general, the term message authentication code (MAC) is used for symmetric methods, while the terms signature or digital signature refer to asymmetric methods with different properties and constraints.

4.1 Specification of the safety solution

The SecOC module described in the document provides the necessary functionality to verify the authenticity and freshness of PDU-based communication between ECUs in the vehicle architecture. This method requires both the sending ECU and the receiving ECU to implement a SecOC module. The two SecOC modules are integrated to provide upper and lower layer PduRapi at the sender and receiver. The SecOC modules on both sides usually interact with the PduR module.

On the sender side, the SecOC module creates a secure I-PDU by adding authentication information to the output real I-PDU. Authentication information includes an authenticator (for example, a message authentication code) and an optional freshness value. The freshness value is taken into account when generating the Authenticator, regardless of whether the freshness value is included in the Secure I-PDU payload. When using a freshness counter instead of a timestamp, it is up to the freshness manager to increment the freshness counter before providing authentication information to the receiver.

At the receiving end, the SecOC module checks the freshness and authenticity of the real I-PDU by verifying the authentication information attached by the SecOC module of the sender. In order to verify the authenticity and freshness of a real I-PDU, the secure I-PDU provided to the receiver SecOC should be the same secure I-PDU provided by the sender SecOC and the receiver SecOC should know that the sender SecOC is in The freshness value used during authenticator creation.

4.1.1 Basic entities of a security solution

(1) Real I-PDU and secure I-PDU

The payload of a secure I-PDU consists of the real I-PDU and an authenticator (eg, message authentication code). The payload of a secure I-PDU may optionally include a freshness value used to create an authenticator (eg, MAC). The structural sequence of the content in the safety I-PDU is consistent with the figure below.

The image below is an example of Secure I-PDU content with truncated freshness counter and truncated authenticator (no Secure I-PDU header)

[Specification] All SecOC data directly or indirectly transmitted to the other side of the communication link (such as freshness value, authenticator, data identifier, SecOC message link data...) shall be encoded in big-endian byte order, so that each SecOC module interprets the data in the same way.

[Specification] The fixed I-PDU header shall indicate the length of the real I-PDU in bytes. The length of the header should be configured via the parameter Data Header Length.

(2) Data covered by the authentication procedure

The data for computing the authenticator consists of the SecOCDatDaId of the secure I-PDU, the real I-PDU data and the full freshness value. These are individually concatenated to form the bit array that is passed to the authenticator for generation/verification.

(3) Freshness value

Every secure I-PDU is configured with at least one freshness value. The freshness value refers to a monotonic counter used to ensure the freshness of the secured I-PDU. Such a monotonic counter can be implemented by a separate message counter, called a freshness counter, or by a timestamp value called a freshness timestamp. The freshness value will come from a freshness manager.

[Specification] If the length of the parameter SecOCFreshnessValueTruncLength is less than the actual freshness value, the SecOC shall only include the least significant freshness value up to SecOCFreshnessValueTruncLength in the secure I-PDU. If the parameter SecOCFreshnessValueTruncLength is configured as 0, the freshness value is not included in the secure I-PDU.

[Specification] If the real data freshness is set to TRUE, SecOC shall use a part of the real I-PDU as the freshness. In this case, SecOCAuthDataFreshnessStartPosition determines the start position with the freshness inside the real I-PDU, and SecOC determines its length with bits.

[Specification] The freshness manager provides or receives freshness information in the form of byte array. Freshness is always aligned to the MSB of the first byte in the array. The 15th bit of freshness is the MSB of the second byte, and so on. Unused bits in the freshness array must be set to 0. The associated length information must be given in bits.

[Specification] If for SecOCQueryFreshnessValue=CFUNC and SecOCProvideTxTruncatedFreshnessValue=TRUE, SecOC calls the interface function SecOC_GetTxFreshnessTruncData whenever a data verifier is constructed for the corresponding PDU.

[Specification] If for SecOCQueryFreshnessValue=CFUNC and SecOCProvideTxTruncatedFreshnessValue=FALSE, SecOC calls the interface function SecOC_GetTxFreshness whenever a data verifier is constructed for the corresponding PDU.

[Specification] If for SecOCQueryFreshnessValue=RTE and SecOCProvideTxTruncatedFreshnessValue=TRUE, SecOC calls the interface function FreshnessManagement_GetTxFreshnessTruncData whenever a data verifier is constructed for the corresponding PDU.

[Specification] If for SecOCQueryFreshnessValue=RTE and SecOCProvideTxTruncatedFreshnessValue=FALSE, SecOC calls the interface function FreshnessManagement_GetTxFreshness whenever a data verifier is constructed for the corresponding PDU.

[Specification] For each transfer request queued to SecOC, an authentication build counter shall be maintained.

[Specification] When initially processing a secure I-PDU transmission request, the SecOC shall set the authentication build counter to 0.

[Specification] If a query to a freshness function (such as SecOC_GetTxFreshness()) returns E_BUSY or a computation to an authenticator (such as Csm_MacGenerate()) returns E_BUSY, QUEUE_FULL, or any other recoverable error, the authentication build counter shall be incremented.

[Specification] If the build verification fails, and the verification build counter has not reached the configured value SecOCAuthenticationBuildAttempts, the freshness attempt and authenticator calculation should be retried the next time the Tx main function is called.

[Specification] If the verification build counter reaches the configuration value SecOCAuthenticationBuildAttempts, or the query of the freshness function returns E_NOT_OK, or the calculation of the authenticator returns an unrecoverable error, such as returning E_NOT_OK or KEY_FAILURE, if the service SecOC_SendDefaultAuthenticationInformation is enabled to send SecOCDefaultAuthenticationInformationPattern, the SecOC module will send SecOCDefaultAuthenticationInformationPattern to the freshness All bytes of degree value and authenticator use SecOCDefaultAuthenticationInformationPattern to build authentication information. If sending of SecOCDefaultAuthenticationInformationPattern is not enabled, the SecOc module shall delete the real I-PDU from its internal buffer and cancel the transmission request.

[Specification] If SecOCProvideTxTruncatedFreshnessValue=TRUE for SecOCQueryFreshnessValue=CFUNC, SecOC will call a function named SecOC_GetTxFreshnessTruncData to get the current freshness of TX message.

[Specification] If for SecOCQueryFreshnessValue = CFUNC, SecOCProvideTxTruncatedFreshnessValue = FALSE, then SecOC will call a function named SecOC_GetTxFreshness to get the current freshness of TX message.

[Specification] If the PDU configuration SecOCQueryFreshnessValue = CFUNC, SecOC calls the function with the signature described in SWS_SecOC_91005 to indicate that the secure I-PDU has successfully initiated the transmission.

[Specification] If the PDU is configured with SecOCQueryFreshnessValue = RTE, the SecOC calls the service operation FreshnessManagement_SPduTxConfirmation to indicate that the secure I-PDU has successfully initiated transmission.

[Specification] For each secure I-PDU processed in SecOC, an authentication build counter and an authentication verification attempt counter shall be maintained.

[Specification] Upon initial processing of a received Security I-PDU, the Authentication Build Counter and Authentication Verification Attempt Counter shall be set to zero.

[Specification] If a query to a freshness function (such as SecOC_GetRxFreshness()) returns E_BUSY, the authentication build counter shall be incremented and no authentication verification attempt shall be performed.

[Specification] If verification to a verifier (such as Csm_MacVerify()) returns E_BUSY, QUEUE_FULL, or any other recoverable error, the verification build counter should be incremented.

[Specification] If the authentication build attempt fails, and the authentication build counter has not reached the configured value SecOCAuthenticationBuildAttempts, the freshness attempt and authenticator verification will be retried in the next call to the Rx main function.

[Specification] If the verification of the authenticator can be successfully performed, but the verification fails (such as MAC verification failure or invalid key), the verification verification attempt counter should be increased, and the verification construction counter should be set to 0.

[Specification] If the authentication build counter has reached the configured value SecOCAuthenticationBuildAttempts, the SecOC module shall delete the real I-PDU from its internal buffer and shall delete the received message. Authentication result type should be set to SECOC_AUTHENTICATIONBUILDFAILURE. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are processed according to the overload status value.

[Specification] If the query to the freshness function returns E_NOT_OK, the SecOC module will delete the real I-PDU from its internal buffer and will delete the received message. Validation result type should be set to SECOC_FRESHNESSFAILURE.

[Specification] If the authentication verification attempt counter reaches the configured value SecOCAuthenticationVerifyAttempts, or the verification of the authenticator returns an unrecoverable error, such as returning E_NOT_OK or KEY_FAILURE, the SecOC module shall delete the real I-PDU from its internal buffer and delete the received news. Verification result type should be set to SECOC_VERIFICATIONFAILURE. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are processed according to the overload status value.

[Specification] If the verification is successful, the verification result type should be set to SECOC_VERIFICATIONSUCCESS.

[Specification] The freshness management shall use the verification status marking function (SWS_SECOC_00119) to obtain the verification result of a secure I-PDU. This notification can be used as an example to synchronize additional freshness attempts, or for counter increments.

[Specification] If the SecOCQueryFreshnessValue=RTE and SecOCUseAuthDataFreshness=TRUE of the PDU configuration, and the secure PDU is completely received, SecOC will call the RTE service FreshnessManagement_GetRxFreshnessAuthData to query the current freshness. Part of the received PDU data is configured for this service operation by configuring SecOCAuthDataFreshnessStartPosition and SecOC.

[Specification] If the SecOCQueryFreshnessValue=RTE and SecOCUseAuthDataFreshness=FALSE of the PDU configuration, and the secure PDU is completely received, SecOC will call the RTE service FreshnessManagement_GetRxFreshness to query the current freshness. Part of the received PDU data is configured for this service operation by configuring SecOCAuthDataFreshnessStartPosition and SecOC.

[Specification] If the SecOCQueryFreshnessValue=CFUNC and SecOCUseAuthDataFreshness=TRUE of the PDU configuration, and the secure PDU is completely received, SecOC will call the RTE service SecOC_GetRxFreshnessAuthData to query the current freshness. Part of the received PDU data is configured for this service operation by configuring SecOCAuthDataFreshnessStartPosition and SecOC.

[Specification] If the SecOCQueryFreshnessValue=CFUNC and SecOCUseAuthDataFreshness=FALSE of the PDU configuration, and the secure PDU is completely received, SecOC will call the RTE service SecOC_GetRxFreshness to query the current freshness. Part of the received PDU data is configured for this service operation by configuring SecOCAuthDataFreshnessStartPosition and SecOC.

[Specification] If the Rx freshness request function returns E_NOT_OK, the verification of the real I-PDU is considered to have failed, and the authentication retry counter of the PDU will be incremented. If the number of authentication attempts has reached SecOCAuthenticationVerifyAttempts, the SecOC module shall delete the real I-PDU from its internal buffer. Fault SECOC_E_FRESHNESS_FAILURE should be reported to DET module.

[Specification] If SecOCQueryFreshnessValue = CFUNC and SecOCUseAuthDataFreshness = TRUE , SecOC queries the function named SecOC_GetRxFreshnessAuthData to obtain the current freshness of RX messages.

[Specification] If SecOCQueryFreshnessValue = CFUNC and SecOCUseAuthDataFreshness = FALSE , SecOC queries the function named SecOC_GetRxFreshness to obtain the current freshness of RX messages.

4.1.2 Secure I-PDU construction

[Specification] Creating a secure I-PDU to authenticate a real IPDU includes the following six steps:

Prepare a secure I-PDU
Construct the data for the authenticator
generate authenticator
Build a secure I-PDU
Increase freshness counter
Broadcast Security I-PDU

[Specification] The SecOC module should prepare secure I-PDU. During the preparation process, SecOC shall allocate necessary buffers to save the intermediate and final results of the authentication process.

[Specification] The SecOC module should build data to the authenticator, that is, the data used to calculate the authenticator. The data authenticator is formed by concatenating the full 16-bit representation of the data Id (parameter SecOCDataId), the security part of the real I-PDU and the full freshness value corresponding to the SecOCfrestnessValueID in the given order. For this purpose, the DataId and Freshness values shall be encoded in big-endian byte order.

[Specification] The SecOC module should generate the authenticator by introducing the data to the authenticator and the length of the data to the authenticator into the authentication algorithm corresponding to SecOCTxAuthServiceConfigRef.

[Specification] The SecOC module shall truncate the resulting authenticator to the number of digits specified by the running length of the SecOC authentication information.

[Specification] The SecOC module shall construct a secure I-PDU by adding the secure I-PDU header (optional), freshness value (optional), and authenticator. The scheme of the safety I-PDU (including the sequence in which the content is structured in the safety I-PDU) shall comply with the following requirements:

4.1.3 Secure I-PDU Verification

[Specification] The verification of safety I-PDU includes the following six steps:

Parse real I-PDU, freshness value and authenticator
Get the freshness value from the freshness manager
Build data for authentication
Verify authentication information
Send acknowledgment to freshness manager
Pass real I-PDU to upper layer

[Specification] If SecOCRxSecuredPduCollection is used, the SecOC shall not perform any verification until it has received the real I-PDU and the encrypted I-PDUI-PDU that constitute the secured I-PDU. Only after both have received the SecOC should an attempt be made to verify the final Secure I-PDU. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are processed according to the overload status value.

[Specification] If SecOCRxSecuredPduCollection is used, then SecOC shall not try to verify the secured I-PDU until it has received and buffered the real I-PDU and the encrypted I-PDU value. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are processed according to the overload status value.

[Specification] After receiving the secure I-PDU, SecOC shall parse the real I-PDU, freshness value and authenticator from it.

[Specification] The SecOC module should be built on the data used to calculate the authenticator (data to the authenticator) on the receiving end. The data consists of SecOCDataId | AuthenticIPDU | FreshnessVerifyValue.

[Specification] The SecOC module shall verify the authenticator by passing the data authenticator, the length of the data authenticator, the authenticator parsed from the security I-PDU, and the length of the data authentication information to SecOCRxAuthServiceConfigRef. The corresponding authentication algorithm repeats the description in Chapter 9.2 verification process. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are processed according to the overload status value.

[Specification] The SecOC module shall report the verification status of the corresponding secure Rx-PDU as follows: If the SecOCRxPduProcessing/SecOCVerificationStatusPropagationMode is set to BOTH or FAILURE_ONLY, the verification status is provided through the call function SecOC_VerificationStatusCallout and SecOC_VerificationStatus interfaces according to the current configuration. If configure is set to NONE, no reports will be provided.

[Specification] The SecOC module shall report the verification status of the corresponding secure Rx-PDU as follows: If the SecOCRxPduProcessing/SecOCClientServerVerificationStatusPropag status mode is set to BOTH or FAILURE_ONLY, the verification status is provided through the service interface SecOC_VerificationStatusIndication according to its current configuration. If configure is set to NONE, no reports will be provided.

[Specification] If the configuration item SecOCGeneral/SecOCPropagateOnlyFinalVerificationStatus is set to TRUE, only the final status will be reported. If this item is set to FALSE, each individual verification status (the last and all previous failed verification statuses) shall be reported according to SWS_SecOC_00048 and SWS_SecOC_00271.

[Specification] If the verification of a secure I-PDU is successful or the status override is set accordingly, the SecOC module shall use the bottom interface of PduR to pass the real I-PDU to the upper communication module.

4.2 Relationship with PduR

[Specification] When implementing a SecOC module, it should be ensured that no other modules depend on it, and if it is not required, a system without a SecOC module can be built.

[Specification] SecOC shall ensure that metadata received in a real PDU will remain unchanged in the corresponding security PDU, and vice versa.

4.3 Initialization

The SecOC module provides an initialization function (SecOC_Init). This function initializes all internal global variables and buffers to store SecOCI-pdu and all intermediate results. The environment of SecOC shall call SecOC_Init before calling any other function of SecOC module except SecOC_GetVersionInfo. Implementers MUST ensure that SecOC_E_UNINIT is returned in development mode if an API function is called before module initialization.

For the I-PDU data transmission path through the SecOC module, a buffer is allocated within the SecOC module. This buffer needs to be initialized because it may be transmitted before the upper layer of the lower communication module is completely filled with data.

[Specification] Within SecOC_Init, the module should initialize all internal global variables and buffers of SecOCI-pdu.

[Specification] The SecOC module uses the value determined by the configuration parameter SecOCTxPduUnusedAreasDefault to fill the unused area of the transmission security or transmission encryption Pdu, such as 0xFF.

4.4 Authentication of outgoing PDUs

[Specification] The SecOC module shall copy the complete real I-PDU into its internal memory before starting to transmit the corresponding secure I-PDU.

[Specification] If SecOCTxSecuredPduCollection is used, the SecOC shall transmit the secured I-PDU as two messages: the original real I-PDU and a separate encrypted I-PDU. The encrypted I-PDU shall contain all the authentication information of the secure I-PDU, so that the real I-PDU and the encrypted I-PDU contain all the information needed to reconstruct the secure I-PDU.

[Specification] SecOC shall transmit a real I-PDU and its corresponding encrypted I-PDU in the same main function cycle.

[Specification] If SecOCTxSecuredPduCollection is used, SecOC will repeat part of the real I-PDU inside the encrypted I-PDU as a message linker, and Cryptographic I-PDU = Authentication Data | Message Linker.

[Specification] If SecOCUse message linking is used, then SecOC shall use the value of the SecOCMessage linker length at the bit position as the message linker.

[Specification] If SecOCTxSecuredPduCollection is used, if the real I-PDU and encrypted I-PDU require SecOC_TxConfirmation, SecOC should forward the Tx confirmation to the upper layer. When the result parameters of the two Tx confirmation calls are both E_OK, the reult parameter of the upper layer Tx confirmation call is only E_OK, otherwise the result parameter should be E_NOT_OK.

[Specification] The SecOC module shall provide sufficient buffer capacity to store the incoming real I-PDU, outgoing secure I-PDU and all intermediate data of the authentication process according to the procedure described in SWS_SecOC_00031.

[Specification] The SecOC module shall provide separate buffers for real I-PDU and secure I-PDU.

[Specification] Any transmission request from the upper layer communication module shall overwrite the buffer containing the real I-PDU, without affecting the buffer of the respective security I-PDU.

[Specification] For a Tx security I-PDU with a SecOC header length of 0, the SecOC module shall add the security I-PDU header to the security I-PDU with the length of the security I-PDU inside the security I-PDU to handle dynamic real I-PDUs.

4.5 Verification of incoming pdu

[Specification] If SecOCReceptionOverflowStrategy is set to replace, if receiving a secure IPDU with the same Pdu identifier is enabled, the SecOC module will release all buffers related to the secure I-PDU.

[Specification] If SecOCReceptionOverflowStrategy is set to deny, and SecOC is currently busy with the same security 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.

[Specification] SecOC shall provide separate buffers for the incoming secure I-PDU, encrypted I-PDU and the resulting real I-PDU.

[Specification] If SecOCReceptionOverflowStrategy is set to queue, and SecOC is currently busy with the same security I-PDU, the SecOC module will additionally receive security I-PDU, and perform subsequent processing after the currently processed security I-PDU is completed. If the limit imposed by the queue size is reached, any further reception will be rejected.

[Specification] For each secure I-PDU that has SecOCRxSecuredPduCollection in the corresponding SecOCRx security layer, SecOC shall only buffer the last real I-PDU and encrypted I-PDU it receives. If the buffer is already filled with a previous I-PDU, the previous I-PDU is overwritten.

[Specification] SecOC should construct and secure I-PDU immediately after receiving the respective authentic real I-PDU and encrypted I-PDU. If SecOC_VerifyStatusOverride is used, the verification result and I-PDU are processed according to the overload status value.

[Specification] If subsequent verification of the generated Secure I-PDU succeeds, the SecOC shall clear the buffers of the real and encrypted I-PDUs.

[Specification] For a secure Rx I-PDU with SecOC actual data length = 0 or not configured, and the dynamic length of the reference global Pdu (see ECUC_EcuC_00078) is set to false, the SecOC module shall use the configured length of the corresponding global Pdu to extract the real I-PDU -PDUs.

[Specification] For SecOC puthpdu header length = 0 or unconfigured security Rx I-PDU, refer to the dynamic length of the global Pdu (see ECUC_EcuC_00078) is set to TRUE, the SecOC module should use the length provided by the lower layer to extract the real I-PDU.

[Specification] For a secure Rx I-PDU with a SecOC data header length > 0, the SecOC module should use the length provided by the secure I-PDU header at runtime to extract the real I-PDU.

4.6 Gateway function

The SecOC module supports authentication and verification of I-pdus routed from one source bus to one or more target buses. This allows implementing re-authentication gateways, which can be used to implement networks with different security zones or properties. Each authentication or verification process for a given I-PDU requires separate configuration. This feature includes:

Authentication of outgoing I-pdus,
Authentication of incoming i-pdu,
Re-authentication gateways, i.e. combining their validation for immediate re-authentication of incoming I-PDUs when they are routed to another lower layer module.

4.7 Multi-core distribution

To provide load distribution among different partitions, different parts of the encryption stack should be assigned to different partitions. Therefore, partitioning on an encrypted instance basis should be supported, that is, encrypted driver instances should be located on different partitions.

[Specification] SecOCTx main function processing should be processed within the main function, through SecOCTxPduMainFunctionRef

4.8 Security Incidents

[Specification] If security event reporting has been enabled for the SecOC module (SecOCEnableSecurityEventReporting = true), the corresponding security events should be reported to IdsM through the interface defined in AUTOSAR_SWS_BSWGeneral.

[Specification] The following table lists the security events standardized for SecOC and their triggering conditions.

[Specification] The following table describes the context data that should be reported for the corresponding security:

4.9 Misclassification

4.9.1 Development errors

4.9.2 Runtime errors

5. API interface

5.1 API definition

SecOC_Init
SecOC_DeInit
SecOC_GetVersionInfo
SecOC_IfTransmit
SecOC_TpTransmit
SecOC_IfCancelTransmit
SecOC_TpCancelTransmit
SecOC_TpCancelReceive
SecOC_VerifyStatusOverride
SecOC_SendDefaultAuthenticationInformation

5.2 Callback interface

SecOC_RxIndication
SecOC_TpRxIndication
SecOC_TxConfirmation
SecOC_TpTxConfirmation
SecOC_TriggerTransmit
SecOC_CopyRxData
SecOC_CopyTxData
SecOC_StartOfReception

5.3 Application callbacks

SecOC_GetRxFreshness
SecOC_GetRxFreshnessAuthData
SecOC_GetTxFreshness
SecOC_GetTxFreshnessTruncData
SecOC_SPduTxConfirmation

5.4 Scheduling functions

SecOC_MainFunctionRx
SecOC_MainFunctionTx

【AUTOSAR】【Information Security】SecOC

I. Overview