AUTOSAR Classic Crypto Services

Le cluster regroupe les modules CSM, CryIf et Crypto Driver afin de fournir, de manière indépendante du matériel, des services cryptographiques et des fonctions de gestion des clés au sein de l'AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. Les jobs cryptographiques sont priorisés via le CSM, routés vers des canaux logiques dans le CryIf et exécutés de manière synchrone ou asynchrone dans le Crypto Driver [SWS_CryIf_91003]. Pour des raisons de cohérence, les persistances de clés dans la NVM ne s'effectuent strictement qu'après une validation réussie au moyen de KeySetValid SWS_CryptoDriver p. 37.

plus ›

Le cluster de modules « Crypto Services & Hardware Abstraction » comprend les modules AUTOSAR Classic Crypto Service Manager (csm), Crypto Interface (cryif) et Crypto Driver (crypto) EXP_UtilizationOfCryptoServices p. 8. Il fournit une couche d'abstraction indépendante du matériel pour les opérations cryptographiques (notamment chiffrement, signatures, calcul de MAC et génération de nombres aléatoires) ainsi que pour une gestion sécurisée des clés [SWS_Csm_00982], [SWS_Csm_00984], SWS_CryptoDriver p. 15.

Les requêtes cryptographiques sont encapsulées sous la forme d'un Crypto_JobType, qui définit des priorités, des mémoires tampon d'entrée et de sortie ainsi que des modes de fonctionnement (Start, Update, Finish pour le streaming ou SingleCall) [SWS_Csm_01013], [SWS_Csm_01039]. Le CSM prend en charge les requêtes, les affecte à des files d'attente logicielles et les transmet via CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. Le CryIf assure le routage des canaux vers les pilotes et traduit les identifiants de clés du CSM en ID de clés de pilote spécifiques aux modules [SWS_CryIf_00133].

Diagramme de contexte : architecture en couches et cascade d'interfaces de la pile cryptographique AUTOSAR. Sources : SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

La synchronisation des requêtes cryptographiques asynchrones repose sur la fonction périodique Csm_MainFunction(), qui vide les files d'attente et déclenche les calculs en attente [SWS_Csm_00479]. Une fois un calcul matériel asynchrone achevé, le Crypto Driver notifie le CryIf via CryIf_CallbackNotification(), lequel retransmet le message à Csm_CallbackNotification() et finalement à l'application appelante [SWS_CryIf_91013], [SWS_Csm_00970].

Diagramme de séquence : déroulement d'une requête cryptographique asynchrone avec mise en file d'attente et cascade de rappels. Sources : [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

La gestion des clés s'effectue via des interfaces standardisées telles que Csm_KeyElementSet() et CryIf_KeyElementCopy(), dans le respect strict des droits d'accès configurés [SWS_Csm_00957], [SWS_CryIf_91015], [SWS_Crypto_00219]. Une persistance dans la NVM n'est déclenchée que lors d'une validation explicite via Crypto_KeySetValid(), ce qui évite les enregistrements de clés incomplets [SWS_Crypto_91014], SWS_CryptoDriver p. 37. Les erreurs telles que les surcharges ou les états de clé invalides sont interceptées de manière robuste via CRYPTO_E_BUSY ou CRYPTO_E_KEY_NOT_VALID [SWS_Csm_00018], [SWS_CryIf_91003].

plus ›

1. Architecture système & rôle du cluster de modules

Le cluster de modules « Crypto Services & Hardware Abstraction » constitue le fondement fonctionnel pour les opérations cryptographiques, la gestion des clés assistée par logiciel et matériel ainsi que la communication embarquée sécurisée au sein de l'AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. L'architecture se structure rigoureusement le long du modèle en couches AUTOSAR en trois modules BSW standardisés : le Crypto Service Manager (csm) dans la couche de service, la Crypto Interface (cryif) dans l'ECU Abstraction Layer ainsi qu'au moins un Crypto Driver (crypto) sur la Microcontroller Abstraction Layer (MCAL) SWS_CryptoDriver p. 15. Cet ensemble de couches abstrait totalement les applications de sécurité (par exemple SecOC, les établissements de connexion TLS et l'authentification de diagnostic UDS) des coprocesseurs cryptographiques propriétaires tels que les Hardware Security Modules (HSM) ou les Secure Hardware Extensions (SHE) SWS_SecureOnboardCommunication p. 78.

Le Crypto Service Manager (CSM) agit en tant que fournisseur de services principal pour les composants logiciels applicatifs (SW-Cs) et les modules BSW de niveau supérieur. Il met à disposition des interfaces de programmation standardisées pour les algorithmes symétriques et asymétriques (par ex. AES, RSA), le hachage, les codes d'authentification de message (MAC), la génération de nombres aléatoires (RNG) et les procédés AEAD [SWS_Csm_00980], [SWS_Csm_00982], [SWS_Csm_00984], [SWS_Csm_01023]. De plus, le CSM met en œuvre des files d'attente de jobs côté logiciel et gère la priorisation des requêtes cryptographiques parallèles [SWS_Csm_00022], SWS_CryptoServiceManager p. 29.

En tant que couche d'abstraction, la Crypto Interface (CryIf) fournit une interface 1:n uniforme entre le CSM et un nombre quelconque de pilotes cryptographiques. Sa tâche centrale est le dispatching : elle achemine les requêtes vers l'instance correspondante du Crypto Driver sur la base de canaux logiques configurés (channelId) et transforme les références logiques de clés (cryIfKeyId) en identifiants spécifiques au pilote (cryptoKeyId) [SWS_CryIf_00133], [SWS_CryIf_91003]. Le Crypto Driver encapsule l'unité d'exécution physique (Crypto Driver Object) et dessert soit des primitives cryptographiques purement logicielles, soit des modules de sécurité matériels dédiés [SWS_Crypto_00224], SWS_CryptoDriver p. 15.

Diagramme de contexte : architecture en couches et cascade d'interfaces de la pile cryptographique AUTOSAR. Sources : SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

2. Interaction & voies d'interaction entre les modules

Le traitement des requêtes au sein du cluster repose principalement sur le modèle basé sur les jobs au moyen de la structure Crypto_JobType [SWS_Csm_01013], AUTOSAR_CP_SWS_CryptoServiceManager p. 21. Un job cryptographique regroupe l'ID de job, des informations de priorité, des références de clés, des métadonnées de primitives et la structure Crypto_JobPrimitiveInputOutputType pour la gestion par pointeurs des paramètres d'entrée, de sortie et de longueur [SWS_Csm_01012]. Le champ de masque de bits Crypto_OperationModeType (comportant les indicateurs START, UPDATE, FINISH) permet de commander si une requête est calculée sous la forme d'un appel unique continu (SINGLECALL) ou de manière incrémentale en mode streaming [SWS_Csm_01039], [SWS_Csm_01029].

Lorsqu'une fonction de service du CSM est appelée de manière synchrone, le CSM vérifie l'état du job. Si le pilote est libre ou si la requête est configurée comme synchrone, le CSM appelle directement CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. Le CryIf mappe les ID de clés et distribue le job à l'instance de pilote assignée via Crypto_ProcessJob() [SWS_CryIf_00133]. En cas de requêtes asynchrones, le job est inséré dans la file d'attente du CSM si l'objet de pilote est occupé [SWS_Csm_00018], AUTOSAR_CP_SWS_CryptoServiceManager p. 30. À l'issue du calcul asynchrone du pilote, ce dernier déclenche CryIf_CallbackNotification() [SWS_CryIf_91013], le CryIf transmet le message à Csm_CallbackNotification() [SWS_Csm_00970], et le CSM notifie finalement l'application demandeuse via son rappel configuré [SWS_Csm_01044], [SWS_Csm_00928].

Diagramme de séquence : déroulement d'une requête cryptographique asynchrone avec mise en file d'attente et cascade de rappels. Sources : [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

Outre l'exécution cryptographique principale, la gestion des clés constitue un chemin d'interaction à part entière du cluster SWS_CryptoDriver p. 24. Une clé se compose de plusieurs éléments de clé logiques (tels que du matériel de clé, des vecteurs d'initialisation ou des valeurs d'itération) [SWS_Csm_00954], [SWS_Csm_01022]. Les opérations telles que la définition de matériel de clé via Csm_KeyElementSet(), la copie au moyen de Csm_KeyElementCopy() ou la dérivation de clé via Csm_KeyDerive() sont transmises de manière synchrone aux fonctions du pilote par l'intermédiaire du CryIf (CryIf_KeyElementCopy(), CryIf_KeyDerive()) [SWS_Csm_00957], [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_CryIf_91009]. L'accès aux éléments de clé est alors strictement contrôlé sur la base des droits d'accès configurés (CRYPTO_RA_ALLOWED, CRYPTO_RA_ENCRYPTED, CRYPTO_RA_INTERNAL_COPY) [SWS_Crypto_00219].

3. Synchronisation, réentrance et contextes de tâche

Les opérations cryptographiques varient considérablement en durée d'exécution. Alors que les chiffrements par blocs rapides ou les calculs de hachage peuvent être exécutés de manière synchrone dans le contexte de tâche de l'appelant, les calculs asymétriques (par ex. la génération de signature RSA) ou les opérations matérielles longues exigent un traitement asynchrone [SWS_Csm_00984], [SWS_Csm_00992]. Pour assurer ce découplage, le CSM fournit la fonction principale Csm_MainFunction(), appelée cycliquement [SWS_Csm_00479]. Celle-ci surveille les files d'attente, distribue les jobs en attente au CryIf et fait progresser les machines à états internes des primitives asynchrones [SWS_Csm_00019].

Dans les architectures multicœurs et multisecteurs modernes, le CSM prend en charge plusieurs instances Csm_MainFunction_<shortName>() qui sont assignées à des partitions d'OS dédiées [SWS_Csm_00479], AUTOSAR_SWS_CryptoServiceManager p. 170. En cas d'exécution asynchrone du pilote, les calculs se terminent soit par scrutation (polling) dans la MainFunction du pilote, soit par des routines de service d'interruption (ISR) de moteurs cryptographiques matériels [SWS_Crypto_00027], [SWS_Crypto_00028]. Par définition, un Crypto Driver Object individuel ne peut traiter simultanément qu'un seul job cryptographique à la fois ; un pilote doté de n objets traite n requêtes en véritable parallélisme [SWS_Crypto_00014], [SWS_Crypto_00117].

En matière de réentrance, les interfaces de service telles que Csm_MacGenerate() ou CryIf_ProcessJob() sont conçues pour être réentrantes pour des jobs différents, mais interdisent la soumission parallèle multiple d'une même instance de job [SWS_Csm_00016], [SWS_CryIf_91003]. Les fonctions de gestion des clés telles que Csm_KeyElementCopy(), CryIf_KeyElementCopy() ou Crypto_KeyCopy() sont implémentées de manière réentrante, mais ne doivent pas être appliquées de façon concurrente au même identifiant de clé source (keyId ou cryptoKeyId), afin d'éviter les incohérences de données et les conditions de concurrence [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_Crypto_00155]. Les pilotes matériels utiliseraient des zones exclusives internes (Exclusive Areas) pour modifier les zones de travail internes et les registres de clés, afin d'intercepter les conditions de concurrence entre le niveau ISR et le niveau tâche SWS_CryptoDriver p. 27. Question Q-b1e9578255723a0e (ouverte)

Diagramme d'activité : logique de décision et découplage par file d'attente lors de l'acceptation de requêtes dans le CSM. Sources : AUTOSAR_CP_SWS_CryptoServiceManager p. 30, [SWS_Csm_00017], [SWS_Csm_00018]

4. Cycles de vie et modes de fonctionnement typiques

L'initialisation du cluster cryptographique s'effectue selon un ordre hiérarchique au cours du démarrage du BSW. L'EcuM ou le BswM initialise d'abord l'étage de pilote via Crypto_Init() en lui transmettant la configuration Crypto_ConfigType [SWS_Crypto_91016], suivi de la couche d'interface via CryIf_Init() avec CryIf_ConfigType [SWS_CryIf_91118]. Enfin, le CSM est démarré au moyen de Csm_Init(), son pointeur de configuration devant toujours être défini sur NULL_PTR conformément à la spécification [SWS_Csm_00646]. Ce n'est qu'après l'initialisation complète de toutes les couches que des requêtes cryptographiques ou des accès aux clés peuvent être acceptés [SWS_CryIf_00076], [SWS_Crypto_00196].

Un aspect fondamental du cycle de vie des clés est la validation et la persistance en mémoire non volatile (NVM). Après le chargement de nouvelles valeurs de clé via Csm_KeyElementSet(), la clé demeure à l'état « incomplet ou inconnu » [SWS_Csm_00957]. Seul l'appel explicite de Csm_JobKeySetValid() ou Crypto_KeySetValid() vérifie la cohérence et fait passer l'état de la clé à valide [SWS_Csm_91027], [SWS_Crypto_91014]. Pour les clés persistées, seule cette validation déclenche l'enregistrement dans la NVM [SWS_Crypto_91026], SWS_CryptoDriver p. 37. Cela empêche de multiples cycles d'écriture fragmentés en NVM et protège contre les jeux de clés incomplets SWS_CryptoDriver p. 37. Pour la synchronisation avec le NVRAM Manager, le Crypto Driver utilise les rappels Crypto_<vi>_<ai>_NvBlock_ReadFrom_<NvBlock>() et Crypto_<vi>_<ai>_NvBlock_WriteTo_<NvBlock>() ainsi que NvM_WriteBlock() [SWS_Crypto_91024], [SWS_Crypto_91025], [SWS_Crypto_91017].

Les requêtes de streaming en cours peuvent au besoin être interrompues via Csm_SaveContextJob(), sauvegardées dans une mémoire tampon propre à l'application et reprises ultérieurement par restauration du contexte [SWS_Csm_91063], [SWS_Csm_01029]. Avant l'arrêt d'un ECU ou un passage dans des modes basse consommation, les requêtes asynchrones peuvent être annulées de manière contrôlée via Csm_CancelJob(), ce par quoi le CryIf retire les jobs des files d'attente de pilote et des canaux matériels via CryIf_CancelJob() [SWS_Csm_00968], [SWS_CryIf_91014].

5. Gestion des erreurs, traçage DET et dégradation

Le cluster implémente une stratégie de détection et de défense contre les erreurs à plusieurs niveaux. Lorsque le traçage est activé, les erreurs de développement sont directement signalées au module Default Error Tracer (DET) [SWS_Csm_91101], [SWS_Crypto_91017]. Parmi les événements DET typiques figurent les appels de module avant initialisation effective (CRYIF_E_UNINIT, CRYPTO_E_UNINIT), les paramètres de handle ou de clé non valides (CRYIF_E_PARAM_HANDLE, CRYPTO_E_PARAM_HANDLE) ainsi que la transmission de pointeurs nuls [SWS_CryIf_00076], [SWS_CryIf_00134], [SWS_Crypto_00196], [SWS_Crypto_00217].

Les surcharges au temps d'exécution et les pénuries de ressources sont interceptées de manière déterministe via des valeurs de retour définies. Si la file d'attente CSM pour une tâche asynchrone est épuisée, le CSM rejette la requête avec le code d'état CRYPTO_E_BUSY et génère l'erreur d'exécution CSM_E_QUEUE_FULL [SWS_Csm_00018], [SWS_Csm_01089]. Si un tampon de résultat fourni est dimensionné de manière insuffisante, le pilote interrompt l'opération avec CRYPTO_E_SMALL_BUFFER [SWS_Crypto_00195]. Si un service cryptographique fait référence à une clé non initialisée ou explicitement invalidée (par exemple après l'appel de Csm_JobKeySetInvalid() ou Crypto_KeySetInvalid()), les demandes de service échouent de manière contrôlée avec CRYPTO_E_KEY_NOT_VALID ou CRYPTO_E_KEY_EMPTY [SWS_Csm_91002], [SWS_CryIf_91003], [SWS_Crypto_91020].

Des mécanismes de dégradation et de repli sont rendus possibles au niveau système : les applications peuvent vérifier l'état d'intégrité des clés avant la soumission de la tâche via Csm_KeyGetStatus() [SWS_Csm_91047], [SWS_CryIf_91012]. Si un accélérateur cryptographique matériel devait être occupé en permanence ou défaillant, la configuration de canal CryIf permet une route de repli logicielle, pour autant qu'un pilote logiciel redondant soit intégré SWS_CryptoDriver p. 15.