classe ara::diag::Authentication

Le constructeur initialise de manière synchrone un objet de la classe de gestionnaire ara::diag::Authentication pour le traitement des requêtes d'authentification de diagnostic sur un port logiciel [SWS_DM_01124]. Le paramètre specifier fait référence au PortPrototype modélisé, qui doit obligatoirement être typé par un DiagnosticAuthenticationInterface via un DiagnosticAuthenticationPortMapping [SWS_DM_01124]. Le paramètre concurrencyType permet de définir si le framework distribue les appels de méthode de manière concurrente (kConcurrent) ou non thread-safe (kNotConcurrent) [SWS_DM_01124].

La fonction étant déclarée comme noexcept, les appels erronés ne sont pas signalés par des exceptions, mais déclenchent des violations du framework (violations) [SWS_DM_01124] :

• InstanceSpecifierMappingIntegrityViolation : l'identifiant ne peut pas être résolu dans le contexte de l'exécutable ou ne référence aucun PortPrototype [SWS_DM_01124].
• PortInterfaceMappingViolation : le PortPrototype référencé n'est pas modélisé en tant que DiagnosticAuthenticationInterface [SWS_DM_01124].
• ProcessMappingViolation : aucun processus modélisé correspondant n'est trouvé à l'exécution [SWS_DM_01124].
• InstanceSpecifierAlreadyInUseViolation : le InstanceSpecifier a déjà été utilisé pour une instance dans le processus actuel [SWS_DM_01124].

Le constructeur lui-même est thread-safe et sûr vis-à-vis des exceptions (exception safe) [SWS_DM_01124], tandis que le destructeur associé ~Authentication() est spécifié comme non thread-safe [SWS_DM_01125]. Immédiatement après l'instanciation, aucune requête de diagnostic n'est encore transférée : l'application doit d'abord appeler Offer() pour activer le transfert pour le service UDS 0x29 (Authentication avec PKI Certificate Exchange, APCE AUTOSAR_AP_SWS_Diagnostics Tab. 4.1 « Limitations of sub-functions of 0x19 ReadDTCInformation ») par le Diagnostic Manager [SWS_DM_01130]. La validation de certificat est ensuite traitée via VerifyCertificateUnidirectional [SWS_DM_01126], VerifyCertificateBidirectional [SWS_DM_01127] et VerifyOwnership [SWS_DM_01128]. Avant la destruction de l'objet, le transfert doit être arrêté avec StopOffer() [SWS_DM_01131].

À l'aide de la méthode synchrone Offer() de la classe ara::diag::Authentication ([SWS_DM_01130]), une Adaptive Application enregistre son gestionnaire d'authentification auprès de Diagnostic Management (DM). Le DM est ainsi autorisé et mis en mesure de transmettre les requêtes entrantes à ce gestionnaire (AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.1 « Offer »). La fonction ne prend aucun paramètre d'entrée et signale l'issue de l'opération via le type de retour ara::core::Result<void>.

L'appel est déclaré comme noexcept et se révèle donc sûr vis-à-vis des exceptions ([SWS_DM_01130]). Si l'enregistrement échoue parce que le service a déjà été mis à disposition auparavant pour cette instance, le code d'erreur spécifique DiagOfferErrc::kAlreadyOffered est renvoyé dans l'objet Result ([SWS_DM_01130]). De plus, l'interface est spécifiée comme not thread-safe ; les accès parallèles sur la même instance ne doivent probablement pas s'effectuer sans protection et doivent être synchronisés côté application. Question Q-51ab72e4e72a7351 (ouverte)

Dans le cycle de vie du traitement du diagnostic, Offer() correspond directement à la fonction inverse StopOffer() ([SWS_DM_01131], AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 « StopOffer »), qui met fin à nouveau à la transmission des requêtes. Ce patron suit l'approche uniforme de mise à disposition des gestionnaires de diagnostic, telle qu'elle s'applique par exemple aussi à ara::diag::CommunicationControl::Offer ([SWS_DM_00809]) ou ara::diag::DoIPPowerMode::Offer ([SWS_DM_00735]), pour lesquels les requêtes ne peuvent être traitées qu'après une mise à disposition explicite par l'application ([SWS_DM_01525]).

Utilisation

La méthode StopOffer de la classe ara::diag::Authentication (définie dans ara/diag/authentication.h) désactive le transfert des messages de requête par le Diagnostic Manager (DM) vers l'instance [SWS_DM_01131]. L'appel est exécuté de manière synchrone, ne nécessite aucun paramètre d'entrée et n'a pas de valeur de retour AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 « StopOffer ».

Gestion des erreurs et sécurité d'exécution

La fonction est spécifiée comme sûre vis-à-vis des exceptions (noexcept) ; aucun code d'erreur spécifique ni exception n'est défini [SWS_DM_01131].

Concurrence et restrictions

L'opération est expressément désignée comme non sûre pour les threads (« not thread-safe ») [SWS_DM_01131]. Les appels concurrents sur une même instance doivent être synchronisés par l'application appelante.

Interaction et référence architecturale

Le patron de conception de StopOffer est utilisé de manière cohérente dans l'Adaptive Diagnostic Manager à travers divers services et gestionnaires, dont SecurityAccess [SWS_DM_00767], CommunicationControl [SWS_DM_00810], DownloadService [SWS_DM_00793] ainsi que EcuResetRequest [SWS_DM_01017]. Bien que le nom s'inspire de la mise à disposition de services dans ara::com, il s'agit d'une implémentation spécifique au diagnostic AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 « Monitors ». Interprétation : avant la désactivation au moyen de StopOffer, l'instance a typiquement dû recevoir activement des requêtes via une fonction de mise à disposition. Question Q-da990416e53707ed (ouverte)

La méthode de rappel virtuelle pure VerifyCertificateBidirectional de l'interface ara::diag::Authentication ([SWS_DM_01127]) est appelée par le Diagnostic Server dès qu'une requête de diagnostic pour le service UDS 0x29 (Authentication) avec la sous-fonction 0x02 (verifyCertificateBidirectional) parvient et que les vérifications initiales ont été passées avec succès ([SWS_DM_01235], AUTOSAR_AP_SWS_Diagnostics §7.3.2.8.11.3 « Service 0x29 – verifyCertificateBidirectional (0x02) »).

Utilisation et sémantique :\nLe serveur transmet la configuration de communication ainsi que les données de certificat et de challenge reçues du testeur via communicationConfiguration, clientCertificate et clientChallenge conjointement avec metaInfo et le cancellationHandler ([SWS_DM_01127], [SWS_DM_01235]). Les tampons des spans d'entrée restent valides jusqu'à ce que le ara::core::Future renvoyé soit satisfait via la promesse associée ou que l'opération soit interrompue ([SWS_DM_01127]). De manière asynchrone, la méthode renvoie au Diagnostic Server un 4-tuple constitué du challenge serveur, du certificat serveur, du proof-of-ownership calculé et de la clé publique éphémère du serveur ([SWS_DM_01127]).

Interruption et concurrence :\nVia le cancellationHandler, l'application peut scruter l'état actuel au moyen de IsCanceled ou enregistrer par SetNotifier une fonction de notification pour l'interruption de connexion ([SWS_DM_01127]). L'interface est définie comme noexcept et peut être appelée de manière réentrante concernant les requêtes de différents clients ([SWS_DM_01127]). La nécessité pour l'implémentation d'être sûre vis-à-vis des threads est déterminée par le ConcurrencyType transmis dans le constructeur ([SWS_DM_01127]).

Gestion des erreurs et interaction :\nEn cas d'erreur, l'application renvoie un NRC approprié selon l'ISO 14229-1 via DiagUdsNrcErrc ; les valeurs de retour négatives sont traitées séparément par le Diagnostic Server ([SWS_DM_01127], [SWS_DM_01236]). Au sein de l'authentification UDS ([SWS_DM_01226]), la configuration de cette sous-fonction constitue une condition préalable nécessaire si DiagnosticProofOfOwnership est configurée ([SWS_DM_01227], [SWS_DM_01228]).

La méthode de rappel VerifyCertificateUnidirectional de la classe ara::diag::Authentication est appelée par l'instance du Diagnostic Server dès qu'une requête pour le service UDS 0x29 avec la sous-fonction verifyCertificateUnidirectional (0x01) est reçue et a été préalablement vérifiée avec succès (SWS Diagnostics §7.3.2.8.11.2 « Service 0x29 – verifyCertificateUnidirectional (0x01) », [SWS_DM_01230]). Elle réalise l'authentification unidirectionnelle via échange de certificats PKI selon l'ISO 14229-1 ([SWS_DM_01226]).

Sont transmis comme paramètres la configuration de communication (communicationConfiguration), le certificat client (clientCertificate) et le challenge client (clientChallenge) ainsi que des métadonnées et un CancellationHandler ([SWS_DM_01126]). Les spans transmis restent valides jusqu'à ce que le ara::core::Future renvoyé soit satisfait ou que le traitement via le gestionnaire soit interrompu. La méthode renvoie de manière asynchrone un tuple composé du challenge serveur généré et de la clé publique éphémère du serveur ([SWS_DM_01126]).

Si une erreur survient lors de la validation, le future doit être terminé avec un code de réponse négative (NRC) approprié via DiagUdsNrcErrc ([SWS_DM_01126]).

La fonction est spécifiée comme exception safe et peut être appelée de manière réentrante pour des requêtes de différents clients de diagnostic ([SWS_DM_01126]). La sécurité vis-à-vis des threads est conditionnelle ; la nécessité ou non pour l'implémentation d'être thread-safe est déterminée par le ConcurrencyType défini dans le constructeur ([SWS_DM_01126]). Dans le flux global, la configuration de cette vérification est une condition préalable obligatoire si la sous-fonction DiagnosticProofOfOwnership est configurée ([SWS_DM_01227]).

Utilisation et contexte d'appel

La méthode purement virtuelle VerifyOwnership de la classe ara::diag::Authentication est appelée par le Diagnostic Server dès qu'une demande d'authentification du service UDS 0x29 avec la sous-fonction proofOfOwnership (0x03) a été reçue et que les contrôles préparatoires ont réussi [SWS_DM_01240]. La tâche de l'implémentation consiste à vérifier la preuve de possession (Proof of Ownership) transmise par le testeur par rapport au challenge de serveur généré, à l'aide de la clé publique issue du certificat client préalablement échangé [SWS_DM_01128].

Lors de l'appel, le Diagnostic Server transmet les données d'entrée cryptographiques pertinentes ainsi que des objets de contexte AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.5 « VerifyOwnership » :

• clientPOWN : contient le Proof of Ownership fourni par le testeur de diagnostic en réponse au challenge de serveur précédent.
• clientEphemeralPublicKey : clé publique éphémère du client pour l'accord de clés Diffie-Hellman selon l'ISO 14229-1:2020.
• metaInfo : métadonnées de la demande de diagnostic courante.
• cancellationHandler : permet d'interroger une éventuelle annulation (cancellationHandler.IsCanceled) ainsi que d'enregistrer une fonction de notification (cancellationHandler.SetNotifier).

La fonction s'exécute de manière asynchrone et renvoie un ara::core::Future qui, en cas de succès, fournit les informations de clé de session sous forme de vecteur d'octets [SWS_DM_01128].

Gestion des erreurs

Si la vérification de possession ne peut pas être effectuée avec succès, l'application insère un code retour négatif UDS (NRC) approprié conformément à l'ISO 14229-1 via DiagUdsNrcErrc dans le future renvoyé [SWS_DM_01128]. Si la méthode renvoie un tel code d'erreur défini, le Diagnostic Server envoie une Negative Response avec le NRC correspondant au client [SWS_DM_01241].

Concurrence et contraintes

L'interface est définie en tant que noexcept. En ce qui concerne la sécurité des threads, le comportement est considéré comme conditionnel (conditional) : le fait que la méthode doive être implémentée de manière thread-safe est déterminé par le ConcurrencyType spécifié lors de la construction de l'instance [SWS_DM_01128]. Pour les tampons clientPOWN et clientEphemeralPublicKey, il est garanti que leur zone mémoire reste valide jusqu'à ce que la promise soit satisfaite ou que le traitement soit annulé via le cancellationHandler [SWS_DM_01128].

Le destructeur virtuel ~Authentication() termine le cycle de vie d'une instance de la classe ara::diag::Authentication et libère ses ressources [SWS_DM_01125]. La méthode est déclarée dans le fichier d'en-tête #include "ara/diag/authentication.h" du module Diagnostics AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 « Destructor ».

La fonction ne prend aucun paramètre, ne renvoie aucune valeur de retour et est appelée de manière synchrone lors de la destruction de l'objet [SWS_DM_01125]. La qualification en tant que virtual garantit que lors d'une suppression polymorphique via des pointeurs ou des références vers des classes de base, les ressources des classes dérivées sont également nettoyées correctement.

En ce qui concerne la gestion des erreurs, la méthode est spécifiée comme exception safe et porte le spécificateur noexcept [SWS_DM_01125]. Aucun code d'erreur ou d'état n'est renvoyé, et il est garanti qu'aucune exception C++ n'apparaît vers l'extérieur.

Concernant la concurrence, ~Authentication() est classé comme not thread-safe [SWS_DM_01125]. La destruction ne doit donc en aucun cas avoir lieu simultanément avec d'autres appels de méthode de la même instance. Interprétation : l'application utilisatrice devrait être tenue d'achever toutes les opérations d'authentification ou de diagnostic en cours avant la destruction et de protéger l'appel de manière externe contre les accès parallèles. Question Q-41b1c115c1056759 (ouverte) Le destructeur met en œuvre l'exigence de niveau supérieur RS_Diag_04251 AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 « Destructor ».