interface de service VerificationStatusConfigurationByFreshnessId

Dans la gestion de la communication, l'interface de service VerificationStatusConfigurationByFreshnessId sert à manipuler de manière ciblée le comportement de vérification de SecOC pour certaines valeurs de fraîcheur ([SWS_CM_10049]). La méthode VerifyStatusOverride permet aux applications d'accepter, d'ignorer ou de rejeter des messages indépendamment du résultat d'authentification. La méthode fonctionne avec un acquittement en retour et n'évalue le nombre de messages prédéfini que lors d'états limites spécifiques ([SWS_CM_10049]).

plus ›

Rôle et contexte système de l'interface de service

L'interface de service VerificationStatusConfigurationByFreshnessId fournit, au sein de la gestion de la communication (com) d'AUTOSAR Adaptive Platform, une interface fonctionnelle permettant de piloter de manière ciblée le comportement de vérification de SecOC (Secure Onboard Communication) ([SWS_CM_10049]). L'interface suit le modèle client/serveur orienté services de l'architecture ara::com (AUTOSAR_AP_SWS_CommunicationManagement p. 459). Le sous-système SecOC de la gestion de la communication agit généralement en tant que fournisseur de service (Service Provider), implémentant le squelette de service et vérifiant les transmissions de PDU sécurisées entrantes ([SWS_CM_10049]). Les applications de commande – par exemple pour le diagnostic embarqué, l'automatisation des tests ou la simulation de pannes – agissent en tant que consommateurs de service (Service Consumers), demandant des manipulations temporaires ou limitées par compteur des résultats de vérification via un objet proxy de service ([SWS_CM_10049]).

Méthodes, événements et champs

En version 1.0, l'interface de service déclare exactement une méthode nommée VerifyStatusOverride ([SWS_CM_10049]). Aucun événement (Events) ni champ (Fields) n'existe dans cette interface (AUTOSAR_AP_SWS_CommunicationManagement p. 459). La méthode n'est explicitement pas configurée en mode « fire-and-forget » (Fire & Forget: false), raison pour laquelle les appels sont acquittés de manière synchrone ou asynchrone via un objet Future ([SWS_CM_10049]).

La méthode VerifyStatusOverride définit trois paramètres d'entrée obligatoires ([SWS_CM_10049]) :

• freshnessID (type uint16_t) : désigne l'identifiant de fraîcheur unique pour lequel l'opération de forçage doit prendre effet ([SWS_CM_10049]).
• overrideStatus (type OverrideStatus) : détermine, via une valeur d'énumération, si le contrôle d'authentification est exécuté, si le message est rejeté ou transmis, et combien de temps le forçage reste actif ([SWS_CM_10049]).
• numberOfMessagesToOverride (type uint8_t) : définit le nombre d'opérations de vérification consécutives à forcer si une limite basée sur un compteur est utilisée ([SWS_CM_10049]).

Cycle de vie et déroulement du forçage

À l'aide de l'appel de VerifyStatusOverride, une application consommatrice peut manipuler de manière déterministe le comportement standard de SecOC ([SWS_CM_10049]). Cela permet soit de transmettre, soit de rejeter des messages indépendamment du résultat de vérification effectif ou totalement sans contrôle ([SWS_CM_10049]). De plus, un VerificationStatusResult spécifique peut être imposé, ce qui permet de tester de manière contrôlée des mécanismes de traitement des erreurs supplémentaires dans les applications réceptrices ([SWS_CM_10049]).

Le paramètre numberOfMessagesToOverride possède une sémantique conditionnelle : il n'est évalué que si overrideStatus est défini sur l'un des états limites kSecOcOverrideDropUntilLimit, kSecOcOverrideSkipUntilLimit ou kSecOcOverridePassUntilLimit ([SWS_CM_10049]). Dans ces cas, le module SecOC gère probablement un compteur en interne, qui est décrémenté à chaque message entrant avec un freshnessID correspondant jusqu'à ce que la limite supérieure soit atteinte et que le service revienne au fonctionnement normal (interprétation basée sur [SWS_CM_10049]). Pour les autres états, le forçage devrait rester actif de manière persistante jusqu'à ce qu'il soit modifié par un nouvel appel (interprétation). Question Q-e916cb8cb1ee2992 (ouverte)

Diagramme de séquence : déroulement de la configuration du forçage de la vérification via VerifyStatusOverride. Sources : [SWS_CM_10049], AUTOSAR_AP_SWS_CommunicationManagement p. 459.

Traitement des erreurs et retours d'information

Comme VerifyStatusOverride n'est pas un appel « fire-and-forget », l'application appelante reçoit via le ara::core::Future résultant une confirmation de la prise en compte réussie de la configuration ([SWS_CM_10049]). Bien que la spécification au statut DRAFT ne liste aucun code d'erreur applicatif spécifique (AUTOSAR_AP_SWS_CommunicationManagement p. 459), l'implémentation du service devrait acquitter des valeurs de paramètres incorrectes ou des identifiants de fraîcheur inconnus par une erreur (interprétation). Question Q-e810b3bffe576706 (ouverte) Les applications consommatrices doivent donc toujours résoudre et valider le Future avant d'injecter des messages spécifiques aux tests ([SWS_CM_10049]).

L'interface VerificationStatusConfigurationByFreshnessId permet de forcer le comportement de vérification SecOC pour un identifiant de fraîcheur spécifique via la méthode avec réponse VerifyStatusOverride [SWS_CM_10049]. Elle autorise le passage ou le rejet de messages et programme un nombre de statuts consécutifs à écraser lors de l'utilisation des statuts limités par compteur [SWS_CM_10049]. Cette configuration sert principalement à injecter des résultats de vérification ciblés pour déclencher et tester le traitement d'erreurs applicatif AUTOSAR_AP_SWS_CommunicationManagement p. 459.

plus ›

1. Rôle et contexte système de l'interface de service

L'interface de service VerificationStatusConfigurationByFreshnessId fait partie du module de communication com dans la plateforme AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_CommunicationManagement p. 56. Dans l'architecture orientée services (SOA), cette interface fournit un point d'accès standardisé permettant de piloter explicitement les mécanismes de vérification de sécurité SecOC (Secure Onboard Communication). Au sein du système, le composant gérant SecOC ou la couche de communication agit comme fournisseur de service (Provider/Skeleton), tandis qu'une application de test, d'injection de fautes ou de diagnostic spécialisée intervient en tant que consommateur client (Consumer/Proxy) [SWS_CM_10049]. Vraisemblablement, cette séparation permet d'isoler la logique applicative des protocoles sous-jacents tout en offrant une interface de contrôle d'intégrité ciblée.

Cette interface a pour objectif principal d'imposer un comportement spécifique pour un identifiant de fraîcheur donné, indépendamment du résultat nominal de vérification cryptographique des messages reçus [SWS_CM_10049]. Elle est associée à des exigences amont de contrôle et de surveillance SecOC (AUTOSAR_AP_SWS_CommunicationManagement p. 459) et s'inscrit aux côtés d'autres éléments de gestion de statut d'authentification définis dans le standard [SWS_CM_10048], [SWS_CM_10050].

Diagramme de séquence : Déroulement de l'appel de configuration d'écrasement via VerifyStatusOverride. Sources : [SWS_CM_10049].

2. Méthodes, événements et champs

L'interface de service définit la méthode VerifyStatusOverride (version 1.0, statut DRAFT) [SWS_CM_10049], AUTOSAR_AP_SWS_CommunicationManagement p. 459. Cette méthode n'est pas configurée en « Fire & Forget » (propriété Fire & Forget = false) [SWS_CM_10049]. Par conséquent, l'appelant client attend une réponse asynchrone retournée sous forme d'un objet de type future (ara::core::Future) attestant de la prise en compte ou du rejet de la consigne d'écrasement.

La méthode VerifyStatusOverride prend en charge trois paramètres d'entrée explicites [SWS_CM_10049] :

• freshnessID (type uint16_t, direction IN) : identifiant de la valeur de fraîcheur sur lequel l'opération de forçage doit être appliquée [SWS_CM_10049].
• overrideStatus (type énuméré OverrideStatus, direction IN) : définit si la vérification est exécutée, si le message est transmis ou ignoré/rejeté, et la durée ou les conditions de validité de cet état d'écrasement [SWS_CM_10049].
• numberOfMessagesToOverride (type uint8_t, direction IN) : nombre de statuts séquentiels consécutifs à écraser lors de l'utilisation d'un compteur pour la vérification d'authentification [SWS_CM_10049].

3. Cycle de vie, sessions et gestion des compteurs

L'utilisation de cette méthode modifie directement l'état de traitement de la sécurité SecOC pour l'identifiant concerné, permettant d'accepter ou de rejeter un message avec ou sans exécution de la vérification de l'authentificateur cryptographique [SWS_CM_10049]. Elle force un résultat défini pour VerificationStatusResult, rendant possible l'activation et le test des mécanismes applicatifs de traitement d'erreurs et de défaillances [SWS_CM_10049].

La portée temporelle du forçage dépend de la valeur affectée à overrideStatus. Le paramètre numberOfMessagesToOverride n'est pris en compte que lorsque la modalité implique une limite de messages, précisément lorsque overrideStatus prend l'une des valeurs suivantes : kSecOcOverrideDropUntilLimit, kSecOcOverrideSkipUntilLimit ou kSecOcOverridePassUntilLimit [SWS_CM_10049]. Dans ces modes limités, un compteur interne décrémente les occurrences jusqu'à expiration, après quoi le comportement nominal de vérification SecOC est vraisemblablement rétabli [SWS_CM_10049].

4. Gestion des erreurs et retour d'appel

Puisque la méthode ne fonctionne pas en mode Fire & Forget, chaque appel transmet en retour un statut de confirmation ou une erreur applicative vers le proxy client [SWS_CM_10049]. L'application cliente doit inspecter le résultat asynchrone pour vérifier que la configuration a été acceptée par le module de communication AUTOSAR_AP_SWS_CommunicationManagement p. 57. Une requête contenant un identifiant de fraîcheur invalide ou non supporté par la configuration locale provoquera typiquement un échec ou un rejet d'opération au niveau du service [SWS_CM_00155], [SWS_CM_10049].