class ara::diag::SovdProximityChallenge

In the AUTOSAR Adaptive Platform, the interface class serves to implement proximity checks for SOVD operations in the diagnostic environment [SWS_DM_01481]. Applications derive from the class, activate forwarding by Diagnostic Management via Offer(), and provide the requested challenge as well as its subsequent validation asynchronously [SWS_DM_01478]. Concurrent calls to the validation methods follow the concurrency mode selected during construction, whereas registration and destruction are not thread-safe.

more ›

Context

In the AUTOSAR Adaptive Platform, the class ara::diag::SovdProximityChallenge [SWS_DM_01481] serves for the application-side implementation of the interface for proximity challenges in the Service-Oriented Vehicle Diagnostics (SOVD) environment. It forms the bridge between AUTOSAR Diagnostic Management (DM or Diagnostic Server) and the actual vehicle application, which provides the security logic for physical or cryptographic proximity checks AUTOSAR_AP_SWS_Diagnostics §8.56 “Providing the SOVD operation proximity_challenge”. If an SOVD operation is configured to require a proximity challenge (attribute proximityProofRequired is TRUE), Diagnostic Management requests a challenge from the application when processing a diagnostic request and has the response transmitted by the client verified [SWS_DM_01398]. Three main parties are involved in this association: the external SOVD client, the mediating Diagnostic Management, and the using application.

Context diagram: Interaction between SOVD client, Diagnostic Management, and the application class ara::diag::SovdProximityChallenge. Sources: [SWS_DM_01398], [SWS_DM_01481], AUTOSAR_AP_SWS_Diagnostics §8.56 “Providing the SOVD operation proximity_challenge”.

Lifecycle

Instantiation of the handler class takes place via the constructor SovdProximityChallenge [SWS_DM_01480]. This binds the instance to an ara::core::InstanceSpecifier defined in the manifest and specifies via the parameter ConcurrencyType whether subsequent execution is concurrent (kConcurrent) or sequential (kNotConcurrent). The constructor itself is specified as thread-safe [SWS_DM_01480]. After object creation, the handler is initially in a passive state. Diagnostic Management is only authorized to forward requests to the application instance through the explicit call to Offer() [SWS_DM_01478].

Forwarding can be deactivated again at any time using StopOffer() [SWS_DM_01495]. Neither Offer(), StopOffer() nor the virtual destructor ~SovdProximityChallenge() [SWS_DM_01479] are thread-safe. Interpretation: Prior to destroying the object, it may be necessary to call StopOffer() to prevent forwarding to an object that is being torn down. Question Q-b4c66854163f433e (open) In addition, in practice, an application instance is typically held throughout the entire runtime of the diagnostic process to continuously secure SOVD operations. The thread safety of the actual query and validation methods GetChallenge() [SWS_DM_01494] and ValidateResponse() [SWS_DM_01493] is controlled by the ConcurrencyType passed in the constructor.

Usage Path

After successful initialization and service offering using Offer() [SWS_DM_01478], the class responds to requests from Diagnostic Management. If an SOVD client requests a protected operation, the DM calls the pure virtual method GetChallenge() [SWS_DM_01494]. The application generates the proximity token and returns it asynchronously together with the validity time (valid_until) via a ara::core::Future<SovdProximityChallengeType> [SWS_DM_01494]. By default, it is assumed that only a single challenge exists at any time that is valid for all clients and operations, with its lifetime typically being fixed (e.g., to two minutes) AUTOSAR_AP_SWS_Diagnostics §8.56 “Providing the SOVD operation proximity_challenge”. For more complex scenarios, the application can evaluate the passed ara::diag::MetaInfo object in order to perform client- or operation-specific checks AUTOSAR_AP_SWS_Diagnostics §8.56 “Providing the SOVD operation proximity_challenge”.

Diagnostic Management transmits the attribute proximity_challenge in the response body to the client [SWS_DM_01398]. If the client responds with a proximity challenge, the DM forwards this data via ValidateResponse() [SWS_DM_01493]. The passed memory area proximityResponse remains valid until the returned ara::core::Future<ProximityChallengeValidationResultType> is fulfilled or processing is canceled [SWS_DM_01493]. Before shutting down the process, the service is deregistered via StopOffer() [SWS_DM_01495].

Sequence diagram: Call sequence from service offering through challenge retrieval and response validation to service deregistration. Sources: [SWS_DM_01478], [SWS_DM_01494], [SWS_DM_01493], [SWS_DM_01495], [SWS_DM_01398].

Error Scenarios

Already during object creation via the constructor [SWS_DM_01480], the framework checks model consistency and can report the following violations: InstanceSpecifierMappingIntegrityViolation (the identifier cannot be resolved or does not point to a port prototype), PortInterfaceMappingViolation (the port prototype is not typed as DiagnosticSovdProximityChallengeInterface), ProcessMappingViolation (no matching modeled process found), or InstanceSpecifierAlreadyInUseViolation (the identifier is already used in the process) [SWS_DM_01480].

When calling Offer() [SWS_DM_01478], the resulting ara::core::Result<void> returns standardized error codes in case of an error: DiagOfferErrc::kAlreadyOffered if the service is already actively offered for this port, or DiagOfferErrc::kConfigurationMismatch if the monitor configuration does not match the DEXT. No standardized error codes are defined for GetChallenge() [SWS_DM_01494] and ValidateResponse() [SWS_DM_01493]. All member functions of the class are declared as noexcept and guarantee exception safety.