classe apext::com::secoc::FVM

La fonction membre apext::com::secoc::FVM::GetRxFreshness sert à la couche SecOC pour déterminer la valeur de fraîcheur complète pour les messages reçus [SWS_CM_11288]. En tant que paramètres d'entrée, la fonction attend l'identifiant SecOCFreshnessValueID, la valeur de fraîcheur tronquée extraite du message sécurisé dans FVContainer conformément à [SWS_CM_11286] ainsi que le compteur SecOCAuthVerifyAttempts [SWS_CM_11288]. Ce compteur commence avec la valeur 0 lors de la première tentative de vérification et est incrémenté à chaque tentative infructueuse ultérieure du même message [SWS_CM_11288].

La méthode est spécifiée comme noexcept et sûre vis-à-vis des exceptions (AUTOSAR_AP_SWS_CommunicationManagement §C.1.2.2.1.1 « GetRxFreshness »). En raison du retour direct d'un ara::core::Result<FVContainer> sans type future, l'appel devrait être traité de manière synchrone et bloquante. Question Q-2609cb9ffeb0d41d (ouverte) En cas de succès, le résultat contient la valeur de fraîcheur complète pour la vérification MAC ultérieure de l'authentificateur [SWS_CM_11288]. Si la valeur ne peut pas être fournie, la fonction renvoie le code d'erreur récupérable ComSecOcFvmErrc::kFVNotAvailable [SWS_CM_11288].

La détermination de la valeur de fraîcheur fait partie intégrante du chemin de réception de SecOC : l'authentification du message a systématiquement lieu avant les contrôles E2E en aval [SWS_CM_11276] et est couplée au compteur de tentatives d'authentification [SWS_CM_11277]. Aucune exigence spécifique de réentrance ou de sécurité des threads n'est définie dans la norme ; le comportement lors d'appels parallèles devrait donc dépendre de l'implémentation concrète du Freshness Value Manager. Question Q-071e92f80c6e44db (ouverte)

La fonction de bibliothèque synchrone apext::com::secoc::FVM::GetTxFreshness ([SWS_CM_11289]) sert au traitement SecOC pour obtenir la valeur de fraîcheur actuelle lors de l'envoi de messages sécurisés via Communication Management ([SWS_CM_11274], AUTOSAR_AP_SWS_CommunicationManagement p. 224 « SecOC secure channel sending »).

Utilisation et contexte d'appel

L'appel est effectué par ara::com, pour autant qu'une freshnessValueId soit définie dans la configuration pour l'élément d'interface de service concerné ([SWS_CM_11274]) :

• Paramètre : SecOCFreshnessValueID (type std::uint16_t) identifie la valeur de fraîcheur à demander ([SWS_CM_11289]).
• Valeur de retour : un ara::core::Result<FVContainer> ([SWS_CM_11289]). En cas de succès, celui-ci contient un apext::com::secoc::FVContainer ([SWS_CM_11286]) dont la valeur de fraîcheur est utilisée pour le calcul ultérieur de l'authentificateur ou du MAC ([SWS_CM_11274]).
• Sécurité vis-à-vis des exceptions : la fonction est déclarée comme noexcept ([SWS_CM_11289]).

Gestion des erreurs et conditions limites

Si aucune valeur de fraîcheur valide ne peut être fournie, la fonction renvoie un ara::core::Result avec le code d'erreur ComSecOcFvmErrc::kFVNotAvailable (« Freshness Value not available ») avec une sémantique de retour arrière ([SWS_CM_11289]). Aucun message spécifique à DET ou DEM n'est défini pour cette interface dans la norme Adaptive.

Déroulement et concurrence

Au sein du processus d'envoi, l'appel est soumis à un ordre strict ([SWS_CM_11274]) :

1. Le cycle de vie du Freshness Value Manager doit auparavant avoir été géré par ara::com ([SWS_CM_11272]) et l'instance doit avoir été initialisée via apext::com::secoc::FVM::Initialize ([SWS_CM_11273]).
2. Lors de l'envoi, GetTxFreshness s'effectue en aval des calculs de protection E2E ([SWS_CM_11274]).
3. Ensuite, le calcul du MAC, les troncatures optionnelles et l'assemblage du message sécurisé sont effectués ([SWS_CM_11274]).

La spécification reste muette sur la réentrance ; l'implémentation du FVM doit toutefois vraisemblablement être conçue pour être thread-safe ou réentrante si des flux de communication parallèles demandent simultanément des valeurs de fraîcheur. Question Q-a1d3e04b91b6c24d (ouverte)

Utilisation et contexte d'appel

La fonction de bibliothèque synchrone Initialize au sein de la portée apext::com::secoc::FVM sert à l'initialisation de l'implémentation de greffon spécifique au fabricant du Freshness Value Manager (FVM) pour la communication relative à la sécurité via SecOC [SWS_CM_11290]. La déclaration est disponible via l'en-tête apext/com/secoc/fvm.h SWS CommunicationManagement §C.1.2.2.1.3 « Initialize ».

La fonction ne prend aucun paramètre et déclare la sécurité vis-à-vis des exceptions noexcept (exception safe) [SWS_CM_11290]. La gestion du cycle de vie du FVM est obligatoirement prise en charge par le middleware de communication ara::com [SWS_CM_11272], qui procède à l'initialisation du greffon FVM par l'appel explicite de cette interface [SWS_CM_11273]. Interprétation : pour les développeurs d'applications, il n'existe aucun contexte d'appel direct, car la mise à disposition s'effectue sous forme de greffon pour la plateforme et le contrôle incombe entièrement à ara::com. Question Q-5b5c8b1a42c3bd3a (ouverte)

Gestion des erreurs

Le résultat de l'opération est communiqué via le type de retour ara::core::Result<void> [SWS_CM_11290] :

• Succès : en cas d'initialisation réussie, le ara::core::Result contient une valeur vide (value_type est void) [SWS_CM_11290].
• Échec de l'initialisation : si le Freshness Value Manager n'a pas pu être initialisé, un objet d'erreur avec le code d'erreur spécifique ComSecOcFvmErrc::kFVInitializeFailed est renvoyé ; des sémantiques de retour arrière s'appliquent alors pour conserver un état défini [SWS_CM_11290].

Interaction et ordre d'appel

L'initialisation au moyen de Initialize constitue le prérequis fonctionnel pour tous les autres services FVM dans le système [SWS_CM_11273]. Ce n'est qu'après un déroulement réussi que ara::com est autorisé, dans le cadre d'opérations d'émission SecOC après le calcul E2E, à accéder à l'interface apext::com::secoc::FVM::GetTxFreshness afin de récupérer des valeurs de fraîcheur pour les attributs freshnessValueId configurés [SWS_CM_11274].

Utilisation

La méthode synchrone apext::com::secoc::FVM::SetVerificationStatus est appelée par SecOC afin de notifier au Freshness Value Manager (FVM) le résultat d'une vérification [SWS_CM_19999]. Elle est déclarée via l'en-tête apext/com/secoc/fvm.h et requiert deux paramètres AUTOSAR_AP_SWS_CommunicationManagement §C.1.2.2.1.4 « SetVerificationStatus » :

• secOCFreshnessValueID (std::uint16_t) : Identifiant unique de la valeur de fraîcheur.
• secOCVerificationStatus (VerificationStatus) : Résultat de vérification pour l'identifiant spécifié.

Gestion des erreurs et concurrence

La fonction est déclarée comme noexcept et est considérée comme sûre vis-à-vis des exceptions (exception safe) [SWS_CM_19999]. Le type de retour ara::core::Result<void> signale une exécution réussie par un résultat vide. En cas d'erreur, l'objet résultat contient un code d'erreur de type ara::com::ComErrc, bien que la spécification ne définisse aucun code d'erreur standardisé spécifique [SWS_CM_19999].

Interaction et statut

La fonction couple SecOC et le FVM lors de la gestion des valeurs de fraîcheur. Elle possède le statut DRAFT AUTOSAR_AP_SWS_CommunicationManagement §C.1.2.2.1.4 « SetVerificationStatus ». Interprétation : les informations d'état transmises devraient être utilisées en interne par le FVM pour actualiser les états de synchronisation ou les valeurs de compteurs des valeurs de fraîcheur. Question Q-156ad8f991c99b7d (ouverte)