classe ara::diag::SecurityAccess

Utilisation

La méthode purement virtuelle CompareKey de la classe ara::diag::SecurityAccess [SWS_DM_00765] est implémentée côté application afin de valider la clé transmise par le client lors du service UDS 0x27 (SecurityAccess) SWS Diagnostics §7.3.2.8.9 « Service 0x27 – SecurityAccess ». Conjointement avec GetSeed, elle constitue la base du mécanisme statique Seed-Key selon l'ISO 14229-1 [SWS_DM_00863].

Les paramètres de la fonction comprennent :

• key : un ara::core::Span<const std::uint8_t> sur les données de clé à vérifier. Le tampon reste valide jusqu'à ce que la promesse associée soit tenue ou que le traitement soit annulé via le cancellationHandler [SWS_DM_00765].
• metaInfo : méta-informations de la requête de diagnostic entrante [SWS_DM_00765].
• cancellationHandler : permet d'interroger une annulation via cancellationHandler.IsCanceled ainsi que d'enregistrer une fonction de notification via cancellationHandler.SetNotifier en cas d'annulation de la conversation [SWS_DM_00765].

Le résultat de la vérification est mis à disposition de manière asynchrone via ara::core::Future<KeyCompareResultType> [SWS_DM_00765].

Traitement des erreurs et interaction

Si la comparaison de clé échoue ou si une erreur survient pendant le traitement, un Negative Response Code (NRC) approprié selon l'ISO 14229-1 doit être transmis via le futur au moyen de DiagUdsNrcErrc [SWS_DM_00765]. Si la sous-fonction demandée n'est pas configurée pour CompareKey, la requête reçoit une réponse avec le NRC 0x12 (kSubFunctionNotSupported) [SWS_DM_00363]. Le serveur de diagnostic compte les tentatives infructueuses [SWS_DM_00270] et les compare à des valeurs de seuil [SWS_DM_00271].

Si l'accès sécurisé est déverrouillé avec succès, le serveur met à jour en interne le niveau de sécurité [SWS_DM_00846], réinitialise le compteur d'échecs [SWS_DM_00270] et signale l'événement de sécurité SEV_UDS_SECURITY_ACCESS_SUCCESSFUL à l'IdsM [SWS_DM_02019].

Concurrence et restrictions

L'interface est déclarée comme noexcept et est sûre face aux exceptions (exception safe) [SWS_DM_00765]. La sûreté des threads est conditionnelle (conditional) : la nécessité pour l'implémentation d'être sûre pour les threads est déterminée par le ConcurrencyType transmis dans le constructeur de SecurityAccess [SWS_DM_00765].

Utilisation

La méthode purement virtuelle ara::diag::SecurityAccess::GetSeed est appelée par l'instance du serveur de diagnostic dès qu'une requête UDS pour le service 0x27 SecurityAccess est reçue et que la valeur de sous-fonction transmise concorde avec la requestSeedId configurée [SWS_DM_00863]. Cela fait partie de la mise en œuvre conforme aux normes du service 0x27 selon l'ISO 14229-1 [SWS_DM_00236].

L'appel transmet les données utiles fournies par le client de diagnostic via le paramètre securityAccessDataRecord (sous forme de ara::core::Span), les informations de contexte dans metaInfo ainsi qu'un objet de type CancellationHandler [SWS_DM_00764]. Si le client n'a envoyé aucune donnée, le span de données est transmis vide [SWS_DM_00863]. Les données transmises restent valides jusqu'à ce que la promesse associée soit tenue ou que le traitement soit annulé [SWS_DM_00764].

Sémantique asynchrone et concurrence

La fonction renvoie de manière asynchrone un ara::core::Future<ara::core::Vector<std::uint8_t>> qui contient le seed généré [SWS_DM_00764]. Via le cancellationHandler, l'application peut vérifier au moyen de IsCanceled si la conversation a été annulée, ou enregistrer une notification via SetNotifier [SWS_DM_00764]. Un mécanisme de seed statique selon l'ISO 14229-1 doit également être implémenté côté application dans GetSeed SWS Diagnostics §7.3.2.8.9 « Service 0x27 – SecurityAccess ».

Concernant la concurrence, la méthode est conditionnellement sûre pour les threads : la nécessité pour l'implémentation d'être sûre pour les threads est déterminée par le ConcurrencyType transmis au constructeur de SecurityAccess SWS Diagnostics §8.24.2.1.3.2 « GetSeed ».

Gestion des erreurs

Si aucun seed valide ne peut être déterminé, le futur doit être complété avec un Negative Response Code (NRC) approprié selon l'ISO 14229-1 via DiagUdsNrcErrc [SWS_DM_00764]. L'interface est déclarée comme noexcept et sûre face aux exceptions [SWS_DM_00764].

Utilisation

La méthode ara::diag::SecurityAccess::Offer ([SWS_DM_00766]) issue de l'en-tête ara/diag/security_access.h permet au Diagnostic Manager (DM) de router les messages de requête (Request Messages) entrants vers le gestionnaire enregistré pour l'accès de sécurité. L'appel s'effectue de manière synchrone sans paramètre d'entrée et renvoie un ara::core::Result<void>.

Gestion des erreurs

En cas d'erreur, l'objet de retour fournit un code d'erreur. Si le service est déjà enregistré sur l'instance, DiagOfferErrc::kAlreadyOffered est renvoyé ([SWS_DM_00766]). La fonction est déclarée comme noexcept et garantit la sécurité vis-à-vis des exceptions (exception safe).

Concurrence et restrictions

L'interface est spécifiée comme non thread-safe (not thread-safe) ([SWS_DM_00766]). Les appels concurrents sur la même instance doivent être synchronisés par l'application. Interprétation : des appels multiples non coordonnés devraient toujours être rejetés avec kAlreadyOffered sans retrait préalable de l'offre. Question Q-848ccd3c78403eea (ouverte)

Interaction

L'offre de fonctionnalité via Offer suit le modèle d'activation uniforme du diagnostic AUTOSAR Adaptive, tel qu'il est également défini pour ServiceValidation ([SWS_DM_00776]) ou DoIPGroupIdentification ([SWS_DM_00725]). Malgré la similitude de nom avec des interfaces de communication, il s'agit d'une implémentation spécifique au diagnostic qui ne doit pas être confondue avec ara::com (SWS Diagnostics §7.3.4.1.2 « Monitors »).

Utilisation

Le constructeur explicite initialise une instance de ara::diag::SecurityAccess de manière synchrone et sans exception ([SWS_DM_00762]). Il reçoit en paramètre une référence vers un ara::core::InstanceSpecifier ainsi qu'un ConcurrencyType. Le paramètre specifier doit référencer un PortPrototype modélisé, typé par un DiagnosticSecurityLevelInterface. concurrencyType détermine si les méthodes de rappel de l'interface sont exécutées de manière concurrente (kConcurrent) ou non concurrente (kNotConcurrent).

Gestion des erreurs

La fonction est déclarée avec noexcept ([SWS_DM_00762]). En cas de mauvaise configuration de la modélisation, les violations suivantes peuvent survenir :

• InstanceSpecifierMappingIntegrityViolation : Le InstanceSpecifier ne peut pas être résolu dans le contexte d'exécution ou ne fait pas référence à un PortPrototype.
• PortInterfaceMappingViolation : le PortPrototype référencé n'est pas typé en tant que DiagnosticSecurityLevelInterface.
• ProcessMappingViolation : Aucun processus modélisé correspondant n'existe au moment de l'exécution pour l'identifiant d'instance.
• InstanceSpecifierAlreadyInUseViolation : le InstanceSpecifier est déjà utilisé au sein du processus.

Interprétation : La survenance d'une telle violation devrait entraîner, en interne au framework, une interruption à l'exécution ou un traitement de sécurité, étant donné que le constructeur ne signale aucun code d'erreur via une valeur de retour. Question Q-de6e36dc7947326e (ouverte)

Concurrence et restrictions

Le constructeur lui-même est spécifié comme thread-safe ([SWS_DM_00762]). Les constructeurs de copie et de déplacement ainsi que les opérateurs d'affectation correspondants sont explicitement supprimés ([SWS_DM_01617], [SWS_DM_01618], [SWS_DM_01615], [SWS_DM_01616]) ; une instance ne peut donc être ni copiée ni déplacée. Le concurrencyType transmis lors du constructeur conditionne si les méthodes virtuelles GetSeed ([SWS_DM_00764]) et CompareKey ([SWS_DM_00765]) doivent être fournies de manière thread-safe. Le destructeur, en revanche, n'est pas thread-safe ([SWS_DM_00763]).

Interaction

Après l'instanciation, l'application doit appeler Offer ([SWS_DM_00766]) afin que le Diagnostic Server (DM) transmette les requêtes UDS entrantes pour le service 0x27 (SWS Diagnostics §7.3.2.8.9 « Service 0x27 – SecurityAccess », [SWS_DM_00236]). Si la sous-fonction correspond, le serveur transmet les requêtes à GetSeed ([SWS_DM_00863]). La transmission peut être à nouveau désactivée avec StopOffer ([SWS_DM_00767]).

Utilisation

La fonction membre StopOffer de la classe ara::diag::SecurityAccess (en-tête ara/diag/security_access.h) sert à désactiver le transfert des messages de requête entrants provenant du Diagnostic Management (DM) vers l'instance [SWS_DM_00767]. L'appel s'effectue de manière synchrone, n'accepte aucun paramètre et ne renvoie aucune valeur de retour (void) [SWS_DM_00767].

Gestion des erreurs

La fonction est déclarée avec noexcept et classée comme sûre vis-à-vis des exceptions (exception safe) [SWS_DM_00767]. Ni codes d'erreur ni exceptions C++ ne sont signalés ; un comportement erroné ou un état exceptionnel lors du désenregistrement n'est pas prévu dans la spécification de l'interface [SWS_DM_00767].

Concurrence et restrictions

Conformément à la spécification, StopOffer n'est pas sûre au niveau des threads (not thread-safe) [SWS_DM_00767]. Si plusieurs threads d'une Adaptive Application accèdent de manière concurrente à la même instance de ara::diag::SecurityAccess, l'appel doit être synchronisé en externe.

Interaction

La méthode fait partie d'un patron de fonctions inter-modules dans le périmètre du DM. Des méthodes StopOffer similaires existent pour de nombreux autres services de diagnostic tels que :

• ara::diag::Authentication [SWS_DM_01131],
• ara::diag::CommunicationControl [SWS_DM_00810],
• ara::diag::DownloadService [SWS_DM_00793],
• ara::diag::EcuResetRequest [SWS_DM_01017] ainsi que
• ara::diag::GenericRoutine [SWS_DM_00558] et ara::diag::Monitor [SWS_DM_01089].

Bien que le nommage soit inspiré de la fourniture de services dans ara::com, il s'agit d'une implémentation de diagnostic autonome destinée à commander le flux de messages au sein de ara::diag AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 « Monitors ».

Le destructeur virtuel ~SecurityAccess [SWS_DM_00763] met fin au cycle de vie d'une instance de la classe de service ara::diag::SecurityAccess dans le module Diagnostics AUTOSAR_AP_SWS_Diagnostics §8.24.2.1.1.3 « Destructor ». L'interface est mise à disposition via l'en-tête #include "ara/diag/security_access.h" [SWS_DM_00763]. L'exécution s'effectue de manière synchrone, la fonction ne prenant aucun paramètre de transmission ni ne fournissant de valeur de retour [SWS_DM_00763].

Concernant le traitement des erreurs, l'opération est classée comme exception safe et déclarée avec noexcept [SWS_DM_00763]. Elle ne lève par conséquent aucune exception. Aucun code d'erreur spécifique ni message d'erreur destiné aux gestionnaires d'erreurs de développement ou de diagnostic (DET ou DEM) n'est prévu dans la spécification pour la destruction de l'objet [SWS_DM_00763].

En ce qui concerne la concurrence, la fonction est explicitement classée comme not thread-safe [SWS_DM_00763]. Une destruction de l'objet ne doit jamais s'effectuer en même temps que des appels d'autres méthodes sur la même instance. À titre d'interprétation : il devrait être nécessaire de clore de manière ordonnée toutes les activités de diagnostic et d'accès sécurisé en cours de cette instance avant la destruction, car des accès simultanés entraînent un comportement indéfini. Question Q-12c13e3eebd9e574 (ouverte)

En interaction avec la plateforme, la fonction sert à la réalisation des exigences amont RS_AP_00134 et RS_Diag_04005 AUTOSAR_AP_SWS_Diagnostics §8.24.2.1.1.3 « Destructor ».