Crypto Service Manager (CSM)

La fonction synchrone Csm_Init sert à initialiser le module Crypto Service Manager (CSM) conformément à [SWS_Csm_00646]. L'interface est déclarée via l'en-tête Csm.h [SWS_Csm_00646].

Concernant les paramètres et le comportement d'appel, [SWS_Csm_00646] définit les propriétés suivantes :

• Paramètres : configPtr est transmis comme paramètre d'entrée. Il s'agit d'un pointeur vers une structure de configuration sélectionnée de type const Csm_ConfigType* [SWS_Csm_00646]. Aucun paramètre d'entrée/sortie ou de sortie n'est présent [SWS_Csm_00646].
• Valeur de retour : La fonction ne renvoie aucune valeur de retour (void) [SWS_Csm_00646].
• Synchronicité et identification : L'exécution s'effectue de manière synchrone ; l'ID de service est 0x00 [SWS_Csm_00646].

Pour la concurrence et le fonctionnement multi-partition, des exigences spécifiques s'appliquent selon [SWS_Csm_00646] :

• Réentrance : La fonction est non réentrante (Non Reentrant) et ne doit donc pas être appelée de manière concurrente [SWS_Csm_00646].
• Partitionnement : Si le module CSM est assigné à plus d'une partition (c'est-à-dire si des fonctions principales telles que Csm_MainFunction sont réparties sur des partitions), le CSM peut fournir une fonction d'initialisation propre par partition [SWS_Csm_00646].

Interprétation : Comme la spécification définit Csm_Init en tant que fonction d'initialisation, l'appel devrait typiquement avoir lieu pendant la phase de démarrage du système avant l'exécution des tâches cryptographiques régulières. Question Q-f462c3f9f4ed24fc (ouverte)

Utilisation

La fonction Csm_Hash calcule une valeur de hachage cryptographique sur les données d'entrée transmises et enregistre le résultat dans la mémoire de destination [SWS_Csm_00980]. L'interface est déclarée via l'en-tête Csm.h et possède l'ID de service 0x5d [SWS_Csm_00980]. Le comportement d'exécution est soit synchrone, soit asynchrone, selon la configuration respective du job spécifié via jobId [SWS_Csm_00980].

Les paramètres se décomposent comme suit [SWS_Csm_00980] :

• jobId : Identifiant unique du job CSM qui fait appel au service cryptographique.
• mode : Indique le ou les modes d'opération à exécuter.
• dataPtr et dataLength : Pointeur vers les données d'entrée à hacher ainsi que le nombre d'octets à traiter.
• resultPtr : Pointeur vers le tampon dans lequel la valeur de hachage calculée est stockée.
• resultLengthPtr : Avant l'appel, ce pointeur doit contenir la capacité fournie du tampon resultPtr en octets. Une fois le traitement terminé, cette valeur est écrasée par la longueur réelle en octets de la valeur de hachage générée. Si le tampon fourni est plus petit que la longueur totale du résultat, la valeur de hachage est enregistrée tronquée.

Gestion des erreurs et concurrence

La valeur de retour de type Std_ReturnType signale par E_OK une requête réussie et par E_NOT_OK une erreur lors du traitement de l'ordre [SWS_Csm_00980]. Concernant la concurrence, Csm_Hash est spécifiée comme réentrante [SWS_Csm_00980].

La fonction réentrante Csm_MacGenerate (ID de service 0x60, en-tête Csm.h) calcule un Message Authentication Code (MAC) sur les données d'entrée transmises et stocke le résultat à l'adresse cible indiquée [SWS_Csm_00982]. Que le traitement s'effectue de manière synchrone ou asynchrone dépend de la configuration du job référencé via jobId [SWS_Csm_00982].

Le paramètre mode spécifie les modes d'opération à exécuter. Les données d'entrée sont transmises via dataPtr et leur nombre d'octets via dataLength [SWS_Csm_00982]. Le tampon macPtr reçoit le résultat. Via le paramètre d'entrée/sortie macLengthPtr, la taille du tampon mis à disposition doit être transmise lors de l'appel ; une fois la requête terminée, la longueur réelle du MAC calculé y est déposée. Si le tampon est plus petit que le résultat total, le MAC est stocké de manière tronquée [SWS_Csm_00982].

Les valeurs de retour possibles de type Std_ReturnType sont [SWS_Csm_00982] :

• E_OK : Requête exécutée avec succès.
• E_NOT_OK : La demande a échoué.
• CRYPTO_E_BUSY : Le service est encore occupé.
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide.
• CRYPTO_E_KEY_SIZE_MISMATCH : Un élément de clé présente une taille incorrecte.
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé.

La fonction Csm_MacVerify sert, conformément à [SWS_Csm_01050], à la vérification d'un code d'authentification de message (MAC) en vérifiant si le MAC transmis correspond aux données fournies. Le résultat de la vérification est enregistré à l'emplacement mémoire référencé par verifyPtr. Le service est disponible via le fichier d'en-tête Csm.h et est spécifié comme réentrant.

Lors de l'appel, il convient de respecter les paramètres et sémantiques suivants [SWS_Csm_01050] :

• Comportement synchrone ou asynchrone : l'exécution s'effectue de manière synchrone ou asynchrone en fonction de la configuration du job référencé via jobId.
• Mode de fonctionnement : mode (Crypto_OperationModeType) permet de déterminer quels modes d'opération doivent être exécutés.
• Indications de longueur : alors que dataLength indique le nombre d'octets de données pour dataPtr, macLength exige obligatoirement la longueur du MAC à vérifier en bits.

En guise de valeur de retour, la fonction renvoie l'état de la demande sous la forme Std_ReturnType [SWS_Csm_01050] :

• E_OK : La requête a réussi.
• E_NOT_OK : la demande a échoué.
• CRYPTO_E_BUSY : le service est encore occupé.
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide.
• CRYPTO_E_KEY_SIZE_MISMATCH : Un élément de clé présente une taille incorrecte.
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé.

La fonction Csm_Encrypt (ID de service 0x5e, mise à disposition via Csm.h) chiffre les données d'entrée transmises et dépose le texte chiffré dans le tampon de résultat indiqué [SWS_Csm_00984].

Utilisation et sémantique

Pour l'exécution de l'opération, les paramètres suivants sont transmis [SWS_Csm_00984] :

• jobId : Identifiant du job CSM qui utilise le service.
• mode : Identifie le ou les modes d'opération à exécuter (de type Crypto_OperationModeType).
• dataPtr et dataLength : Pointeur vers les données initiales à chiffrer ainsi que le nombre d'octets à traiter.
• resultPtr : Pointeur vers la zone mémoire dans laquelle les données chiffrées sont déposées.
• resultLengthPtr : Pointeur vers l'information de longueur en octets. Avant l'appel, ce paramètre doit contenir la capacité de tampon fournie de resultPtr ; une fois la requête terminée, la longueur de sortie réelle y est enregistrée [SWS_Csm_00984].

La sémantique d'exécution n'est pas fixée statiquement : elle a lieu de manière synchrone ou asynchrone selon la configuration du job associé [SWS_Csm_00984].

Concurrence et restrictions

La fonction est spécifiée comme réentrante [SWS_Csm_00984]. Les appelants doivent garantir que le tampon resultPtr reste valide pendant l'ensemble du traitement jusqu'à l'achèvement de l'opération et qu'il présente au moins la taille indiquée initialement via resultLengthPtr.

Gestion des erreurs et valeurs de retour

La valeur de retour de type Std_ReturnType fournit des indications sur l'état de la requête [SWS_Csm_00984] :

• E_OK : demande réussie.
• E_NOT_OK : La demande a échoué.
• CRYPTO_E_BUSY : Requête rejetée, car le service est actuellement encore occupé.
• CRYPTO_E_KEY_NOT_VALID : La clé indiquée se trouve à l'état « invalid ».
• CRYPTO_E_KEY_SIZE_MISMATCH : Un élément de clé présente une taille non valide.
• CRYPTO_E_KEY_EMPTY : Un élément de clé source non initialisé a été transmis.

La fonction Csm_Decrypt ([SWS_Csm_00989]) déchiffre les données chiffrées transmises et enregistre le texte en clair résultant dans la zone mémoire de destination. Elle est mise à disposition via l'en-tête Csm.h et exécute des opérations cryptographiques basées sur la configuration du job transmis.

Utilisation et paramètres

Le paramètre jobId permet d'adresser le job CSM à utiliser, tandis que mode (type Crypto_OperationModeType) définit la ou les phases d'opération à exécuter ([SWS_Csm_00989]). Les données à déchiffrer sont transmises sous forme de pointeur dataPtr avec le nombre d'octets dataLength. Le texte en clair est écrit dans le tampon référencé par resultPtr.

Le paramètre d'entrée-sortie resultLengthPtr gère la gestion du tampon : lors de l'appel, il doit contenir la taille du tampon de resultPtr fournie en octets ; à l'issue de l'opération, la longueur de sortie réellement écrite y est enregistrée ([SWS_Csm_00989]).

Exécution et valeurs de retour

Le comportement d'exécution (synchrone ou asynchrone) dépend directement de la configuration du job sous-jacent ([SWS_Csm_00989]). La fonction est conçue pour être réentrante et renvoie des valeurs de retour spécifiques de type Std_ReturnType :

• E_OK : La demande a réussi ([SWS_Csm_00989]).
• E_NOT_OK : la requête a échoué ([SWS_Csm_00989]).
• CRYPTO_E_BUSY : le service demandé est actuellement encore occupé ([SWS_Csm_00989]).
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé utilisée n'est pas valide ([SWS_Csm_00989]).
• CRYPTO_E_KEY_SIZE_MISMATCH : un élément de clé possède une taille inadaptée ([SWS_Csm_00989]).
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé ([SWS_Csm_00989]).

Utilisation

La fonction Csm_AEADEncrypt exécute un chiffrement authentifié avec données associées (AEAD) et est disponible via l'en-tête Csm.h [SWS_Csm_01023]. Elle traite via plaintextPtr et plaintextLength le texte en clair à chiffrer ainsi que via associatedDataPtr et associatedDataLength des données associées supplémentaires [SWS_Csm_01023]. Les données de sortie sont écrites dans les tampons ciphertextPtr (texte chiffré) et tagPtr (tag d'authentification ou MAC) [SWS_Csm_01023]. Lors de l'appel, ciphertextLengthPtr et tagLengthPtr doivent contenir la capacité de tampon fournie en octets ; une fois l'opération terminée, ils contiennent la longueur réelle des valeurs de sortie [SWS_Csm_01023] (interprétation : le paramètre resultPtr mentionné dans la spécification devrait, pour des raisons rédactionnelles, faire référence à ciphertextPtr ou tagPtr). Question Q-ea7e69875375c501 (ouverte) Le mode d'opération à exécuter est sélectionné via mode [SWS_Csm_01023]. L'exécution s'effectue de manière synchrone ou asynchrone en fonction de la configuration de job du jobId transmis [SWS_Csm_01023].

Gestion des erreurs et valeurs de retour

Le service fournit les valeurs d'état suivantes via le type de retour Std_ReturnType [SWS_Csm_01023] :

• E_OK : La demande a réussi [SWS_Csm_01023].
• E_NOT_OK : la demande a échoué [SWS_Csm_01023].
• CRYPTO_E_BUSY : La requête a échoué car le service est occupé [SWS_Csm_01023].
• CRYPTO_E_KEY_NOT_VALID : La requête a échoué car l'état de la clé n'est pas valide [SWS_Csm_01023].
• CRYPTO_E_KEY_SIZE_MISMATCH : La requête a échoué car un élément de clé présente une taille incorrecte [SWS_Csm_01023].
• CRYPTO_E_KEY_EMPTY : La requête a échoué en raison d'un élément de clé source non initialisé [SWS_Csm_01023].

concurrence

L'interface est spécifiée comme réentrante [SWS_Csm_01023].

Le service Csm_AEADDecrypt (ID de service 0x63, mis à disposition via Csm.h) effectue un déchiffrement AEAD (Authenticated Encryption with Associated Data) conformément à [SWS_Csm_01026]. Interprétation : bien que la description dans le texte de la spécification mentionne un chiffrement, la fonction sert, au vu des paramètres d'entrée et de sortie définis, au déchiffrement de texte chiffré ainsi qu'à la vérification du tag d'authentification transmis. Question Q-00e8fca03eb3b44d (ouverte)

L'exécution a lieu de manière synchrone ou asynchrone selon la configuration du job identifié via jobId ([SWS_Csm_01026]). En ce qui concerne la concurrence, la fonction est réentrante ([SWS_Csm_01026]). Le paramètre mode permet de spécifier les modes d'opération à traiter.

Les relations entre paramètres suivantes s'appliquent pour l'appel ([SWS_Csm_01026]) :

• Données d'entrée : pointeurs et indications de longueur pour le texte chiffré (ciphertextPtr, ciphertextLength), les données associées (associatedDataPtr, associatedDataLength) et le tag à vérifier (tagPtr, tagLength).
• Données de sortie : le tampon plaintextPtr reçoit le texte en clair déchiffré. Le pointeur plaintextLengthPtr doit contenir la capacité du tampon lors de l'appel ; à l'issue de l'opération, la longueur de sortie réelle y est enregistrée.
• Résultat de la vérification : le résultat de la vérification du tag est renvoyé via verifyPtr.

Selon [SWS_Csm_01026], les valeurs de retour de type Std_ReturnType spécifiées sont :

• E_OK : la requête a réussi.
• E_NOT_OK : la requête a échoué.
• CRYPTO_E_BUSY : le service est occupé.
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide.
• CRYPTO_E_KEY_SIZE_MISMATCH : l'élément de clé possède une taille incorrecte.
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé.

La fonction Csm_SignatureGenerate sert au calcul de signature cryptographique sur les données utiles transmises conformément à [SWS_Csm_00992]. Le fait que l'appel soit traité de manière synchrone ou asynchrone dépend de la configuration respective du job transmis (jobId) [SWS_Csm_00992]. La fonction est spécifiée comme réentrante [SWS_Csm_00992].

Lors de l'appel, le paramètre mode de type Crypto_OperationModeType contrôle les modes d'opération à exécuter [SWS_Csm_00992]. Les données à signer sont transmises via dataPtr avec leur longueur en octets dataLength [SWS_Csm_00992]. La signature calculée est écrite dans la zone mémoire référencée par signaturePtr [SWS_Csm_00992]. Le paramètre d'entrée/sortie signatureLengthPtr doit contenir avant l'appel la taille de tampon fournie en octets ; après l'achèvement de la demande, il contient la longueur réelle en octets de la signature générée [SWS_Csm_00992].

La valeur de retour signale l'état de la demande de la fonction [SWS_Csm_00992] :

• E_OK : demande exécutée ou démarrée avec succès [SWS_Csm_00992].
• E_NOT_OK : erreurs générales lors de la demande [SWS_Csm_00992].
• CRYPTO_E_BUSY : le service demandé est actuellement occupé [SWS_Csm_00992].
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé utilisée n'est pas valide [SWS_Csm_00992].
• CRYPTO_E_KEY_SIZE_MISMATCH : Un élément de clé présente une taille inadaptée [SWS_Csm_00992].
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé [SWS_Csm_00992].

Le service Csm_SignatureVerify (Service-ID 0x64, déclaré dans Csm.h) sert à la vérification d'une signature cryptographique à partir des données transmises [SWS_Csm_00996]. La spécification décrit la fonctionnalité, à titre de comparaison, comme une vérification visant à déterminer si la signature (également appelée MAC dans la description) a été générée avec les données transmises [SWS_Csm_00996].

Utilisation et paramètres : lors de l'appel, jobId identifie le job CSM configuré, tandis que mode (type Crypto_OperationModeType) prescrit les modes d'opération à exécuter [SWS_Csm_00996]. Les données utiles à vérifier sont transmises via le pointeur dataPtr avec le nombre d'octets dataLength [SWS_Csm_00996]. La signature à valider est fournie via signaturePtr accompagnée de sa longueur en octets signatureLength [SWS_Csm_00996]. La fonction enregistre le résultat de vérification à l'emplacement mémoire référencé par le paramètre de sortie verifyPtr (type Crypto_VerifyResultType*) [SWS_Csm_00996]. Le comportement d'exécution est synchrone ou asynchrone, selon la configuration du job concerné [SWS_Csm_00996].

Gestion des erreurs et valeurs de retour : la fonction renvoie un état de type Std_ReturnType qui signale le succès ou des états d'erreur spécifiques de la requête [SWS_Csm_00996] :

• E_OK : la demande de service a réussi [SWS_Csm_00996].
• E_NOT_OK : la demande de service a échoué [SWS_Csm_00996].
• CRYPTO_E_BUSY : la requête a échoué car le service sous-jacent est encore occupé [SWS_Csm_00996].
• CRYPTO_E_KEY_NOT_VALID : La demande a échoué car l'état de la clé n'est pas valide [SWS_Csm_00996].
• CRYPTO_E_KEY_SIZE_MISMATCH : la requête a échoué car un élément de clé possède une taille incorrecte [SWS_Csm_00996].
• CRYPTO_E_KEY_EMPTY : La requête a échoué en raison d'un élément de clé source non initialisé [SWS_Csm_00996].

Concurrence : selon la spécification, la fonction est réalisée de manière réentrante [SWS_Csm_00996].

La fonction Csm_RandomGenerate sert à générer des nombres aléatoires et enregistre le résultat dans la zone mémoire pointée par resultPtr [SWS_Csm_01543].

Utilisation et paramètres

Le paramètre jobId transmet l'identifiant du job CSM configuré qui utilise le service [SWS_Csm_01543]. L'appelant contrôle la quantité de données souhaitée via le paramètre d'entrée/sortie resultLengthPtr : lors de l'appel, ce pointeur doit référencer le nombre d'octets aléatoires à générer qui doivent être stockés dans le tampon resultPtr [SWS_Csm_01543]. Une fois la requête terminée, resultLengthPtr contient la longueur effective en octets de la valeur générée [SWS_Csm_01543]. Le traitement s'effectue de manière synchrone ou asynchrone, selon la configuration du job concerné [SWS_Csm_01543].

Valeurs de retour et gestion des erreurs

La fonction renvoie un statut de type Std_ReturnType [SWS_Csm_01543] :

• E_OK : la requête a réussi [SWS_Csm_01543].
• E_NOT_OK : la requête a échoué [SWS_Csm_01543].
• CRYPTO_E_BUSY : la requête a échoué car le service est encore occupé [SWS_Csm_01543].
• CRYPTO_E_ENTROPY_EXHAUSTED : la requête a échoué car l'entropie du générateur de nombres aléatoires est épuisée [SWS_Csm_01543].

concurrence

La fonction est conçue pour être réentrante et est disponible via l'en-tête Csm.h avec le Service-ID 0x72 [SWS_Csm_01543].

Utilisation et sémantique

La fonction synchrone Csm_KeyElementSet définit les octets d'un élément de clé spécifié pour une clé identifiée par keyId [SWS_Csm_00957]. La fonction possède l'ID de service 0x78 et est disponible via l'en-tête Csm.h [SWS_Csm_00957]. Les paramètres d'entrée suivants sont transmis pour l'appel [SWS_Csm_00957] :

• keyId : Identifiant de la clé pour laquelle le nouveau matériel de clé doit être défini [SWS_Csm_00957].
• keyElementId : Identifiant de l'élément de clé dans lequel écrire [SWS_Csm_00957].
• keyElementPtr : Pointeur vers les octets de l'élément de clé à traiter [SWS_Csm_00957].
• keyElementLength : Nombre d'octets de l'élément de clé à définir [SWS_Csm_00957].

Valeurs de retour et gestion des erreurs

L'exécution renvoie un état de type Std_ReturnType qui indique le succès ou des causes d'erreur spécifiques [SWS_Csm_00957] :

• E_OK : la requête a réussi [SWS_Csm_00957].
• E_NOT_OK : la requête a échoué [SWS_Csm_00957].
• CRYPTO_E_BUSY : Le Crypto Driver Object concerné est occupé [SWS_Csm_00957].
• CRYPTO_E_KEY_WRITE_FAIL : L'accès en écriture à l'élément de clé a été refusé [SWS_Csm_00957].
• CRYPTO_E_KEY_NOT_AVAILABLE : La clé adressée n'est pas disponible [SWS_Csm_00957].
• CRYPTO_E_KEY_SIZE_MISMATCH : La taille de l'élément de clé ne correspond pas à la taille des données fournies [SWS_Csm_00957].

Concurrence et restrictions

La fonction Csm_KeyElementSet est spécifiée comme synchrone et non réentrante (Non Reentrant) [SWS_Csm_00957]. Elle ne possède aucun paramètre d'entrée/sortie (inout) ou de sortie (out) [SWS_Csm_00957].

La fonction synchrone Csm_KeySetValid sert à définir l'état de clé d'une clé adressée via l'identifiant keyId sur valide (« valid ») après la mise à disposition de nouveau matériel de clé [SWS_Csm_00958]. Le service est fourni via l'en-tête Csm.h et possède le Service-ID 0x67 [SWS_Csm_00958].

Pour l'utilisation et les valeurs de retour, les stipulations suivantes s'appliquent selon [SWS_Csm_00958] :

• Paramètre d'entrée : l'identifiant de la clé pour laquelle le nouveau matériel doit être validé est transmis via keyId.
• Valeur de retour E_OK : la demande de validation de l'état de clé a réussi.
• Valeur de retour E_NOT_OK : la demande a échoué.
• Valeur de retour CRYPTO_E_BUSY : la requête a échoué car le Crypto Driver Object sous-jacent est occupé.

Concernant la concurrence, Csm_KeySetValid est spécifié comme non réentrant (« Non Reentrant ») [SWS_Csm_00958]. Les appelants devraient donc devoir assurer une synchronisation appropriée si des appels proviennent potentiellement de contextes concurrents. Question Q-1762a3bca77ab74e (ouverte)

La fonction synchrone Csm_KeySetInvalid définit l'état d'une clé sur non valide [SWS_Csm_91075]. Une clé définie comme non valide ne peut plus être utilisée pour des opérations cryptographiques tant qu'elle n'a pas été ramenée dans un état valide [SWS_Csm_91075].

Utilisation et paramètres

L'appel est disponible via l'en-tête Csm.h et est exécuté de manière synchrone [SWS_Csm_91075]. L'identifiant de la clé à invalider est transmis via le paramètre d'entrée keyId (type uint32) [SWS_Csm_91075].

Valeurs de retour et gestion des erreurs

La fonction renvoie une valeur d'état de type Std_ReturnType [SWS_Csm_91075] :

• E_OK : la demande d'invalidation a réussi [SWS_Csm_91075].
• E_NOT_OK : la requête a échoué [SWS_Csm_91075].
• CRYPTO_E_BUSY : la demande a échoué car l'objet pilote cryptographique est occupé [SWS_Csm_91075].

Concurrence et restrictions

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Csm_91075]. Les appelants doivent donc s'assurer que les appels ne s'effectuent pas avec interruption ou en parallèle de façon non coordonnée. Si l'objet pilote cryptographique responsable est occupé au moment de l'appel, l'opération est rejetée avec CRYPTO_E_BUSY [SWS_Csm_91075].

Utilisation

La fonction synchrone Csm_KeyGetStatus sert à interroger l'état actuel d'une clé spécifiée via son identifiant [SWS_Csm_91047]. La déclaration est disponible via l'en-tête Csm.h [SWS_Csm_91047].

Lors de l'appel, les paramètres suivants sont transmis [SWS_Csm_91047] :

• keyId (entrée) : Identifiant de la clé dont l'état doit être déterminé.
• keyStatusPtr (sortie) : Pointeur vers un emplacement mémoire de type Crypto_KeyStatusType dans lequel le CSM dépose l'état de clé déterminé.

Comme valeur de retour, la fonction fournit Std_ReturnType [SWS_Csm_91047] :

• E_OK : L'interrogation d'état a réussi et le résultat est disponible via le pointeur de sortie.
• E_NOT_OK : la requête a échoué.

Concurrence et comportement

La fonction de service possède l'ID de service 0x83 et est spécifiée comme réentrante [SWS_Csm_91047]. Comme le déroulement est synchrone, l'appel bloque l'appelant jusqu'à l'achèvement de la détermination de l'état [SWS_Csm_91047]. Une zone mémoire valide pour keyStatusPtr doit être fournie par l'appelant, car des pointeurs non valides conduisent vraisemblablement à la valeur de retour E_NOT_OK. Question Q-a920a9a12b1374aa (ouverte)

La fonction synchrone et réentrante Csm_KeyElementGet lit les données d'un élément de clé spécifique à partir de la clé identifiée via keyId et les copie dans la zone mémoire transmise [SWS_Csm_00959]. Le service est déclaré via le fichier d'en-tête Csm.h et possède le Service-ID 0x68 [SWS_Csm_00959].

Paramètres et gestion du tampon

Pour identifier l'élément, les paramètres keyId (identifiant de la clé) et keyElementId (identifiant de l'élément de clé souhaité) sont transmis [SWS_Csm_00959]. La lecture requiert la mise à disposition d'un tampon de sortie ainsi que la gestion de sa longueur :

• keyElementPtr : pointeur vers l'emplacement mémoire où les octets extraits de l'élément de clé sont copiés [SWS_Csm_00959].
• keyElementLengthPtr : un paramètre d'entrée/sortie (inout) qui doit contenir, lors de l'appel de fonction, la taille de tampon maximale disponible de keyElementPtr en octets. Une fois le traitement terminé, la fonction y stocke la longueur en octets effectivement écrite [SWS_Csm_00959].

Valeurs de retour et analyse des erreurs

La fonction renvoie des codes d'état spécifiques en tant que Std_ReturnType afin d'indiquer l'issue de l'opération [SWS_Csm_00959] :

• E_OK : l'opération de copie de l'élément de clé a réussi [SWS_Csm_00959].
• E_NOT_OK : la requête a échoué de manière générale [SWS_Csm_00959].
• CRYPTO_E_BUSY : la requête a échoué car le Crypto Driver Object concerné est actuellement occupé [SWS_Csm_00959].
• CRYPTO_E_KEY_NOT_AVAILABLE : l'élément de clé demandé via keyElementId n'est pas disponible [SWS_Csm_00959].
• CRYPTO_E_KEY_READ_FAIL : l'accès en lecture à l'élément de clé a été refusé [SWS_Csm_00959].
• CRYPTO_E_KEY_EMPTY : l'élément de clé source demandé n'est pas initialisé [SWS_Csm_00959].

La fonction synchrone Csm_KeyElementCopyManager sert à copier un élément de clé individuel depuis une clé source vers un élément cible d'une clé cible [SWS_Csm_00969]. L'appel est mis à disposition via le fichier d'en-tête Csm.h avec le Service-ID 0x71 et nécessite quatre paramètres d'entrée : keyId et keyElementId pour l'identification de l'élément de clé source ainsi que targetKeyId et targetKeyElementId pour la cible [SWS_Csm_00969].

En ce qui concerne la concurrence, le service est conçu pour être réentrant, mais explicitement pas pour la même keyId [SWS_Csm_00969]. Les accès parallèles à la même clé source doivent donc être évités ou synchronisés par l'appelant.

La fonction renvoie un état de type Std_ReturnType. En cas d'exécution réussie, elle fournit E_OK [SWS_Csm_00969]. En cas d'erreur, des valeurs de retour spécifiques sont disponibles pour l'analyse des causes [SWS_Csm_00969] :

• CRYPTO_E_BUSY : l'objet pilote crypto sous-jacent est occupé [SWS_Csm_00969].
• CRYPTO_E_KEY_NOT_AVAILABLE : l'élément de clé demandé n'est pas disponible [SWS_Csm_00969].
• CRYPTO_E_KEY_READ_FAIL : la lecture de l'élément source n'est pas autorisée [SWS_Csm_00969].
• CRYPTO_E_KEY_WRITE_FAIL : l'écriture dans l'élément cible n'est pas autorisée [SWS_Csm_00969].
• CRYPTO_E_KEY_SIZE_MISMATCH : les tailles des deux éléments de clé sont incompatibles entre elles [SWS_Csm_00969].
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas encore initialisé [SWS_Csm_00969].
• E_NOT_OK : erreurs générales lors de l'exécution de la demande [SWS_Csm_00969].

Utilisation

La fonction de service synchrone Csm_KeyCopy portant le Service-ID 0x73 sert à la copie complète de tous les éléments de clé d'une clé source vers une clé cible [SWS_Csm_01034]. La déclaration est mise à disposition via le fichier d'en-tête Csm.h [SWS_Csm_01034]. keyId pour l'identifiant de la clé source et targetKeyId pour l'identifiant de la clé cible sont transmis comme paramètres d'entrée non modifiables [SWS_Csm_01034]. Aucun paramètre supplémentaire d'entrée/sortie ou de sortie n'est défini dans la signature [SWS_Csm_01034].

Gestion des erreurs et valeurs de retour

La valeur de retour de type Std_ReturnType informe l'appelant du résultat de l'exécution [SWS_Csm_01034]. Alors que E_OK signale une exécution réussie, E_NOT_OK caractérise un échec général de la requête [SWS_Csm_01034]. Des causes d'erreur spécifiques sont indiquées par des valeurs de retour cryptographiques distinctes [SWS_Csm_01034] :

• CRYPTO_E_BUSY : l'opération a échoué car le Crypto-Driver-Objekt est occupé.
• CRYPTO_E_KEY_NOT_AVAILABLE : l'élément de clé demandé n'est pas disponible.
• CRYPTO_E_KEY_READ_FAIL : la lecture de l'élément de clé depuis la source n'est pas autorisée.
• CRYPTO_E_KEY_WRITE_FAIL : l'écriture de l'élément de clé dans la cible n'est pas autorisée.
• CRYPTO_E_KEY_SIZE_MISMATCH : les tailles des éléments de clé impliqués ne sont pas compatibles entre elles.
• CRYPTO_E_KEY_EMPTY : l'élément de clé de la clé source n'est pas initialisé.

Concurrence et restrictions

Concernant le comportement d'appel, Csm_KeyCopy est conçu pour être réentrant, avec toutefois la restriction contraignante que cela ne s'applique pas pour le même keyId [SWS_Csm_01034].

La fonction synchrone Csm_KeyElementCopyPartial copie une sous-partie définie d'un élément de clé dans un autre élément de clé au sein du même pilote cryptographique [SWS_Csm_91025]. Les paramètres keyElementSourceOffset et keyElementCopyLength déterminent à partir de quel octet et sur quelle longueur l'élément source (identifié par keyId et keyElementId) est copié. La position de départ dans l'élément cible (targetKeyId, targetKeyElementId) est indiquée via keyElementTargetOffset [SWS_Csm_91025].

La valeur de retour fournit l'état d'exécution ainsi que des causes d'erreur spécifiques [SWS_Csm_91025] :

• E_OK : l'opération de copie a été exécutée avec succès.
• CRYPTO_E_BUSY : le Crypto-Driver-Objekt est occupé.
• CRYPTO_E_KEY_NOT_AVAILABLE : l'élément de clé demandé n'est pas disponible.
• CRYPTO_E_KEY_READ_FAIL : la lecture de l'élément de clé source n'est pas autorisée.
• CRYPTO_E_KEY_WRITE_FAIL : l'écriture de l'élément de clé cible n'est pas autorisée.
• CRYPTO_E_KEY_SIZE_MISMATCH : les tailles des éléments de clé impliqués sont incompatibles.
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé.
• E_NOT_OK : la requête a échoué pour des raisons générales.

La fonction est implémentée de manière réentrante, mais ne doit pas être appelée simultanément pour le même keyId [SWS_Csm_91025]. De plus, l'interface suppose que la source et la cible sont gérées dans le même pilote cryptographique [SWS_Csm_91025]. La déclaration est disponible via l'en-tête Csm.h [SWS_Csm_91025].

Utilisation et contexte d'appel

La fonction synchrone Csm_RandomSeed sert à renseigner l'élément de clé CRYPTO_KE_RANDOM_SEED d'une clé avec une valeur aléatoire (graine) transmise [SWS_Csm_01051]. Lors de l'appel, l'identifiant de la clé cible est transmis via keyId, le pointeur vers l'emplacement mémoire contenant les données de graine via seedPtr et la longueur de la graine en octets via seedLength [SWS_Csm_01051].

Interaction

Si le CSM ne détecte aucune erreur lors de l'exécution, la fonction Csm_RandomSeed transmet directement l'appel de service à CryIf_RandomSeed du Crypto Interface [SWS_Csm_01052].

Gestion des erreurs et valeurs de retour

La fonction renvoie une valeur d'état de type Std_ReturnType [SWS_Csm_01051] :

• E_OK : la requête a réussi [SWS_Csm_01051].
• E_NOT_OK : la requête a échoué [SWS_Csm_01051].
• CRYPTO_E_BUSY : l'exécution a échoué car le Crypto Driver Object correspondant est actuellement occupé [SWS_Csm_01051].
• CRYPTO_E_KEY_NOT_VALID : la demande a été rejetée car l'état de la clé n'est pas valide [SWS_Csm_01051].

Concurrence et restrictions

En ce qui concerne le comportement de concurrence, Csm_RandomSeed est implémentée de manière réentrante, mais ne doit pas être appelée simultanément pour le même keyId [SWS_Csm_01051].

La fonction synchrone Csm_KeyGenerate sert à générer du nouveau matériel de clé cryptographique et stocke celui-ci directement dans la clé définie via le paramètre keyId [SWS_Csm_00955]. L'interface est fournie via le fichier d'en-tête Csm.h et possède le Service-ID 0x6a [SWS_Csm_00955].

Lors de l'appel, l'application transmet l'identifiant keyId (type uint32) de la clé pour laquelle le matériel doit être généré ; il n'existe pas de paramètres d'entrée/sortie ou de purs paramètres de sortie [SWS_Csm_00955]. L'état de l'opération est signalé de manière synchrone via la valeur de retour de type Std_ReturnType [SWS_Csm_00955] :

• E_OK : la génération et le stockage du matériel de clé ont réussi [SWS_Csm_00955].
• E_NOT_OK : la requête a échoué [SWS_Csm_00955].
• CRYPTO_E_BUSY : l'exécution a échoué car l'objet pilote cryptographique responsable est actuellement occupé [SWS_Csm_00955].
• CRYPTO_E_KEY_NOT_VALID : la requête a été rejetée car la clé cible se trouve dans l'état « invalid » [SWS_Csm_00955].
• CRYPTO_E_KEY_EMPTY : la génération a échoué en raison d'un élément de clé source non initialisé [SWS_Csm_00955].

Concernant la concurrence, Csm_KeyGenerate est conçu pour être réentrant, mais ne doit pas être appelé de manière concurrente pour le même keyId [SWS_Csm_00955].

La fonction synchrone Csm_KeyDerive sert à dériver une nouvelle clé cryptographique à partir d'une clé d'origine spécifiée [SWS_Csm_00956]. La fonction est déclarée dans le fichier d'en-tête Csm.h et possède le Service-ID 0x6b [SWS_Csm_00956].

Utilisation et paramètres

L'appel synchrone traite deux paramètres d'entrée [SWS_Csm_00956] :

• keyId : identifiant de la clé d'origine qui contient les éléments de clé pour le mot de passe et le sel [SWS_Csm_00956].
• targetKeyId : identifiant de la clé cible ; le matériel de clé dérivé est stocké dans l'élément de clé portant l'ID 1 [SWS_Csm_00956].

Valeurs de retour et gestion des erreurs

Comme valeur de retour, la fonction fournit l'état Std_ReturnType [SWS_Csm_00956]. En plus de E_OK en cas d'exécution réussie et de E_NOT_OK lors d'erreurs générales, des erreurs cryptographiques spécifiques sont définies [SWS_Csm_00956] :

• CRYPTO_E_BUSY : l'objet pilote cryptographique est occupé [SWS_Csm_00956].
• CRYPTO_E_KEY_READ_FAIL : la lecture de l'élément de clé n'est pas autorisée [SWS_Csm_00956].
• CRYPTO_E_KEY_WRITE_FAIL : l'écriture dans l'élément de clé cible n'est pas autorisée [SWS_Csm_00956].
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide [SWS_Csm_00956].
• CRYPTO_E_KEY_SIZE_MISMATCH : les tailles des éléments de clé sont incompatibles [SWS_Csm_00956].
• CRYPTO_E_KEY_EMPTY : l'élément de clé de la source n'est pas initialisé [SWS_Csm_00956].

Concurrence et interaction

La fonction est réentrante, mais expressément pas pour le même keyId [SWS_Csm_00956]. Si aucune erreur n'est constatée dans le CSM, le service transmet immédiatement l'exécution à CryIf_KeyDerive [SWS_Csm_01018].

L'interface synchrone Csm_KeyExchangeCalcPubVal (Service-ID 0x6c, disponible via Csm.h) calcule la valeur publique de l'utilisateur actuel pour le protocole d'échange de clés et stocke la clé publique à l'adresse mémoire référencée par le pointeur publicValuePtr [SWS_Csm_00966].

Paramètres et gestion de tampon

La fonction traite trois paramètres de transmission [SWS_Csm_00966] :

• keyId (entrée) : contient l'identifiant de la clé qui doit être utilisée pour le protocole d'échange de clés [SWS_Csm_00966].
• publicValuePtr (sortie) : pointeur vers la zone mémoire dans laquelle la valeur de clé publique résultante est stockée [SWS_Csm_00966].
• publicValueLengthPtr (entrée/sortie) : pointeur vers l'information de longueur. Lors de l'appel, ce paramètre doit contenir la taille fournie du tampon publicValuePtr ; une fois l'exécution terminée, la longueur réelle de la valeur calculée y est enregistrée [SWS_Csm_00966].

Gestion des erreurs et valeurs de retour

L'état d'exécution est retourné via Std_ReturnType [SWS_Csm_00966] :

• E_OK : La demande a réussi [SWS_Csm_00966].
• E_NOT_OK : la demande a échoué [SWS_Csm_00966].
• CRYPTO_E_BUSY : la requête a échoué car l'objet pilote cryptographique est occupé [SWS_Csm_00966].
• CRYPTO_E_KEY_NOT_VALID : la requête échoue car l'état de la clé n'est pas valide [SWS_Csm_00966].
• CRYPTO_E_KEY_EMPTY : la requête échoue en raison d'un élément de clé source non initialisé [SWS_Csm_00966].

concurrence

La fonction est conçue pour être réentrante, mais ne doit pas être appelée simultanément pour le même keyId [SWS_Csm_00966].

La fonction synchrone Csm_KeyExchangeCalcSecret sert, dans le Crypto Service Manager, au calcul d'un secret partagé (Shared Secret Key) dans le cadre d'un protocole d'échange de clés [SWS_Csm_00967]. Le matériel de clé de la clé référencée via keyId est ici combiné avec la valeur publique du partenaire de communication. La clé secrète calculée est ensuite directement déposée en tant qu'élément de clé au sein de la même clé [SWS_Csm_00967].

L'interface est fournie via l'en-tête Csm.h et attend trois paramètres d'entrée [SWS_Csm_00967] :

• keyId : identifiant de la clé dont le matériel de clé est utilisé pour le protocole.
• partnerPublicValuePtr : pointeur vers la zone mémoire contenant la valeur publique du partenaire.
• partnerPublicValueLength : longueur de la valeur du partenaire transmise, en octets.

L'appel fournit comme valeur de retour de type Std_ReturnType soit E_OK en cas d'exécution réussie, soit E_NOT_OK lors d'une erreur générale [SWS_Csm_00967]. Des cas d'erreur spécifiques sont signalés par des codes d'état détaillés : CRYPTO_E_BUSY indique que le Crypto-Driver-Objekt sous-jacent est occupé. Si l'état de la clé n'est pas valide, CRYPTO_E_KEY_NOT_VALID est renvoyé, tandis que CRYPTO_E_KEY_EMPTY signale un élément de clé source non initialisé [SWS_Csm_00967].

Concernant la concurrence, la fonction est conçue pour être réentrante, mais ne doit pas être appelée simultanément pour le même keyId [SWS_Csm_00967].

Utilisation

La fonction Csm_JobKeySetValid enregistre la clé si nécessaire et définit l'état de clé de la clé identifiée via keyId sur valide [SWS_Csm_91027]. L'interface est déclarée via le fichier d'en-tête Csm.h et possède l'ID de service 0x7a avec la signature Std_ReturnType Csm_JobKeySetValid (uint32 jobId, uint32 keyId) [SWS_Csm_91027].

Lors de l'appel, deux paramètres d'entrée de type uint32 sont transmis [SWS_Csm_91027] :

• jobId : Contient l'identifiant du job qui utilise le service CSM [SWS_Csm_91027].
• keyId : Contient l'identifiant de la clé pour laquelle le nouveau matériel de clé doit être validé [SWS_Csm_91027].

Aucun paramètre d'entrée/sortie supplémentaire ou paramètre de sortie pur n'est défini pour cette fonction [SWS_Csm_91027].

Comportement synchrone et asynchrone ainsi que concurrence

La sémantique d'exécution dépend de la configuration respective du job : l'appel a lieu soit de manière synchrone, soit de manière asynchrone [SWS_Csm_91027]. La fonction est spécifiée comme réentrante [SWS_Csm_91027].

Valeurs de retour et gestion des erreurs

La valeur de retour de type Std_ReturnType reflète le résultat de la requête de fonction [SWS_Csm_91027] :

• E_OK : La demande a réussi [SWS_Csm_91027].
• E_NOT_OK : la demande a échoué [SWS_Csm_91027].
• CRYPTO_E_BUSY : La requête a échoué car le Crypto Driver Object concerné est occupé [SWS_Csm_91027].

Utilisation

La fonction Csm_JobKeySetInvalid définit l'état d'une clé cryptographique sur non valide [SWS_Csm_91002]. Après l'appel de cette interface, la clé concernée ne peut plus être utilisée pour des opérations cryptographiques jusqu'à ce qu'elle ait été remise dans un état valide [SWS_Csm_91002]. Le service possède le Service-ID 0x84, est disponible via le fichier d'en-tête Csm.h et fonctionne de manière synchrone ou asynchrone selon la configuration du job [SWS_Csm_91002].

Les paramètres suivants sont transmis pour l'appel [SWS_Csm_91002] :

• jobId : identifiant du job CSM qui utilise ce service [SWS_Csm_91002].
• keyId : identifiant de la clé à invalider [SWS_Csm_91002].

Gestion des erreurs et valeurs de retour

La valeur de retour de type Std_ReturnType signale le résultat de la demande [SWS_Csm_91002] :

• E_OK : la requête a réussi [SWS_Csm_91002].
• E_NOT_OK : la requête a échoué [SWS_Csm_91002].
• CRYPTO_E_BUSY : la demande a échoué car le Crypto Driver Object responsable est occupé [SWS_Csm_91002].

concurrence

L'interface est spécifiée comme réentrante [SWS_Csm_91002]. Il n'existe pas de paramètres d'entrée ou de sortie supplémentaires [SWS_Csm_91002].

Utilisation et contexte d'appel

La fonction Csm_JobRandomSeed sert à fournir une nouvelle graine pour une clé définie, qui est utilisée pour un générateur de nombres aléatoires associé [SWS_Csm_91028]. La déclaration est disponible dans l'en-tête Csm.h [SWS_Csm_91028]. La fonction possède l'ID de service 0x7b et traite quatre paramètres d'entrée : jobId identifie le job CSM utilisateur, tandis que keyId détermine la clé cible pour laquelle la graine doit être générée [SWS_Csm_91028]. Les données d'initialisation sont transmises via le pointeur seedPtr et leur longueur en octets est définie par seedLength [SWS_Csm_91028]. Le comportement d'exécution dépend de la configuration du job respectif et s'effectue de manière synchrone ou asynchrone [SWS_Csm_91028].

Gestion des erreurs et valeurs de retour

La fonction renvoie un statut de type Std_ReturnType qui indique le résultat de la requête [SWS_Csm_91028] :

• E_OK : la requête a réussi [SWS_Csm_91028].
• E_NOT_OK : la requête a généralement échoué [SWS_Csm_91028].
• CRYPTO_E_BUSY : la requête a échoué car le service est actuellement encore occupé [SWS_Csm_91028].
• CRYPTO_E_KEY_NOT_VALID : la requête a été rejetée car la clé spécifiée se trouve dans l'état invalid [SWS_Csm_91028].

Concurrence et restrictions

L'interface est spécifiée comme réentrante [SWS_Csm_91028]. Si une application appelle le service alors qu'une autre opération est encore active, la valeur de retour CRYPTO_E_BUSY signale cet état [SWS_Csm_91028]. De plus, il doit être garanti avant l'exécution que la clé adressée via keyId est valide afin d'éviter l'erreur CRYPTO_E_KEY_NOT_VALID [SWS_Csm_91028].

Utilisation

La fonction Csm_JobKeyGenerate génère du nouveau matériel de clé et le stocke dans la clé identifiée via keyId [SWS_Csm_91029]. L'identifiant du job qui utilise le service CSM est transmis via le paramètre jobId [SWS_Csm_91029]. L'exécution s'effectue de manière synchrone ou asynchrone selon la configuration du job concerné [SWS_Csm_91029]. Le service est déclaré via le fichier d'en-tête Csm.h avec le Service-ID 0x7c [SWS_Csm_91029].

Valeurs de retour et gestion des erreurs

La valeur de retour de type Std_ReturnType fournit des informations sur le résultat de la requête [SWS_Csm_91029] :

• E_OK : la requête a réussi [SWS_Csm_91029].
• E_NOT_OK : la requête a échoué [SWS_Csm_91029].
• CRYPTO_E_BUSY : le service est actuellement encore occupé [SWS_Csm_91029].
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide (invalid) [SWS_Csm_91029].
• CRYPTO_E_KEY_EMPTY : la requête a échoué en raison d'un élément de clé source non initialisé [SWS_Csm_91029].

Concurrence et restrictions

La fonction est spécifiée comme réentrante [SWS_Csm_91029]. Interprétation : étant donné que la spécification ne définit aucun contexte d'exécution spécifique, l'appel devrait typiquement s'effectuer dans le contexte d'une tâche. Question Q-236d699ed655e285 (ouverte)

Utilisation et sémantique

La fonction Csm_JobKeyDerive dérive une nouvelle clé cryptographique en utilisant les éléments de clé pour le mot de passe et le sel issus de la clé identifiée par keyId [SWS_Csm_91030]. Le résultat est stocké dans l'élément de clé d'ID 1 de la clé cible définie par targetKeyId [SWS_Csm_91030]. L'appel s'effectue via le fichier d'en-tête Csm.h avec l'ID de service 0x7d en transmettant le job respectif via jobId [SWS_Csm_91030].

Le traitement s'effectue de manière synchrone ou asynchrone selon la configuration du job transmis [SWS_Csm_91030]. La fonction est spécifiée comme réentrante [SWS_Csm_91030].

Gestion des erreurs et valeurs de retour

Comme valeur de retour, la fonction renvoie le type Std_ReturnType. Une exécution réussie de la requête est confirmée par E_OK [SWS_Csm_91030]. En cas d'erreur ou de préconditions inappropriées, des valeurs de retour spécifiques sont signalées [SWS_Csm_91030] :

• E_NOT_OK : la demande a échoué [SWS_Csm_91030].
• CRYPTO_E_BUSY : la requête échoue car le service est actuellement encore saturé [SWS_Csm_91030].
• CRYPTO_E_KEY_READ_FAIL : la lecture de l'élément de clé n'est pas autorisée [SWS_Csm_91030].
• CRYPTO_E_KEY_WRITE_FAIL : l'écriture dans l'élément de clé cible n'est pas autorisée [SWS_Csm_91030].
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide [SWS_Csm_91030].
• CRYPTO_E_KEY_SIZE_MISMATCH : les tailles des éléments de clé impliqués ne sont pas compatibles entre elles [SWS_Csm_91030].
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé [SWS_Csm_91030].

Utilisation

La fonction Csm_JobKeyExchangeCalcPubVal calcule la valeur publique du participant actuel pour le protocole d'échange de clés et la stocke dans la mémoire cible indiquée [SWS_Csm_91031]. Selon la configuration du job associé, le traitement s'effectue de manière synchrone ou asynchrone [SWS_Csm_91031].

La transmission des paramètres s'effectue via les données d'interface suivantes [SWS_Csm_91031] :

• jobId : identifiant du job CSM qui sollicite le service cryptographique.
• keyId : identifiant de la clé utilisée pour le protocole d'échange de clés.
• publicValuePtr : pointeur vers la zone de tampon dans laquelle la clé publique calculée est enregistrée.
• publicValueLengthPtr : pointeur vers l'indication de longueur. Lors de l'appel de fonction, ce paramètre doit contenir la capacité du tampon publicValuePtr ; une fois l'exécution terminée, la longueur réelle de la valeur calculée y est inscrite.

Gestion des erreurs

La valeur de retour de type Std_ReturnType fournit des informations sur l'état d'exécution de la requête [SWS_Csm_91031] :

• E_OK : la requête a été exécutée avec succès.
• E_NOT_OK : la requête a échoué.
• CRYPTO_E_BUSY : le service demandé est actuellement encore occupé.
• CRYPTO_E_KEY_NOT_VALID : l'état de la clé n'est pas valide.
• CRYPTO_E_KEY_EMPTY : l'élément de clé source n'est pas initialisé.

Concurrence et intégration

L'interface est déclarée réentrante, possède l'ID de service 0x7e et est fournie via le fichier d'en-tête Csm.h [SWS_Csm_91031].

Utilisation et sémantique

La fonction Csm_JobKeyExchangeCalcSecret calcule la clé secrète partagée (Shared Secret Key) pour un échange de clés en utilisant le matériel de clé issu de la clé identifiée par keyId ainsi que la clé publique du partenaire de communication [SWS_Csm_91032]. L'adresse mémoire de la clé du partenaire est transmise via partnerPublicValuePtr et sa longueur en octets est définie par partnerPublicValueLength [SWS_Csm_91032]. Le secret partagé calculé est directement enregistré comme élément de clé au sein de cette même clé [SWS_Csm_91032].

Le paramètre d'entrée jobId permet d'identifier le job CSM utilisateur. Le comportement d'exécution est synchrone ou asynchrone, selon la configuration du job respectif [SWS_Csm_91032].

Gestion des erreurs et valeurs de retour

La valeur de retour de type Std_ReturnType signale l'état de la demande de service [SWS_Csm_91032] :

• E_OK : la demande de service a réussi [SWS_Csm_91032].
• E_NOT_OK : la demande de service a échoué [SWS_Csm_91032].
• CRYPTO_E_BUSY : la requête échoue car le service sous-jacent est encore occupé [SWS_Csm_91032].
• CRYPTO_E_KEY_NOT_VALID : la requête échoue car la clé référencée se trouve dans l'état « invalid » [SWS_Csm_91032].
• CRYPTO_E_KEY_EMPTY : le calcul échoue car un élément de clé source requis n'est pas initialisé [SWS_Csm_91032].

Concurrence et intégration

La fonction est conçue pour être réentrante, possède l'ID de service 0x7f et est déclarée via le fichier d'en-tête Csm.h [SWS_Csm_91032].

La fonction Csm_SaveContextJob demande au Crypto Driver de sauvegarder le contexte interne de l'opération cryptographique concernée dans un tampon côté application [SWS_Csm_91063]. Le service est déclaré dans le fichier d'en-tête Csm.h et possède le Service-ID 0x86 [SWS_Csm_91063].

L'interface attend les paramètres suivants [SWS_Csm_91063] :

• jobId (entrée) : désigne l'identifiant unique du job qui utilise le service CSM.
• contextBufferLengthPtr (entrée/sortie) : pointeur vers la valeur de longueur. Lors de l'appel, il indique la capacité maximale disponible dans le tampon cible ; après l'exécution, il contient la longueur de données réellement écrite ou, en cas d'erreur, la valeur 0.
• contextBufferPtr (sortie) : pointeur vers la zone mémoire de l'application dans laquelle les données de contexte doivent être écrites.

L'exécution s'effectue de manière synchrone ou asynchrone selon la configuration du job [SWS_Csm_91063]. De plus, la fonction est spécifiée comme réentrante [SWS_Csm_91063].

Pour le compte-rendu de l'état de l'opération, les valeurs de retour suivantes sont définies [SWS_Csm_91063] :

• E_OK : les données de contexte ont été enregistrées avec succès dans le tampon et l'indication de longueur a été mise à jour.
• E_NOT_OK : les données de contexte n'ont pas pu être fournies car les valeurs sont invalides ; la longueur renvoyée est définie sur 0.
• CRYPTO_E_BUSY : la requête a échoué car le service cryptographique sous-jacent est encore occupé.

Utilisation et sémantique

La fonction Csm_RestoreContextJob sert à restaurer l'état interne d'un job cryptographique à partir d'un tampon externe, de sorte que les opérations suivantes reprennent à l'emplacement exact de la sauvegarde précédente [SWS_Csm_91064]. Le job cible est adressé via le paramètre jobId, tandis que contextBufferPtr pointe vers les données utiles et contextBufferLength vers leur taille en octets [SWS_Csm_91064]. L'exécution s'effectue de manière synchrone ou asynchrone selon la configuration du job respectif [SWS_Csm_91064].

Valeurs de retour et gestion des erreurs

La fonction signale le résultat de l'opération via sa valeur de retour de type Std_ReturnType [SWS_Csm_91064] :

• E_OK : les données de contexte ont été lues avec succès et l'état interne du pilote a été restauré [SWS_Csm_91064].
• E_NOT_OK : la restauration du contexte a échoué [SWS_Csm_91064].
• CRYPTO_E_BUSY : le service cryptographique sous-jacent est actuellement occupé, raison pour laquelle la requête a été rejetée [SWS_Csm_91064].

Concurrence et restrictions

L'interface est spécifiée comme réentrante et disponible via Csm.h (ID de service 0x87) [SWS_Csm_91064]. Interprétation : dans le cas d'une configuration asynchrone du job, l'appelant devrait devoir veiller à ce que le tampon sous contextBufferPtr reste inchangé et valide jusqu'à l'achèvement effectif de la restauration. Question Q-8ab0cb179f807bd4 (ouverte)

Utilisation et contexte d'appel

La fonction Csm_CancelJob (ID de service 0x6f) sert à interrompre de manière synchrone le traitement de jobs asynchrones ou de streaming au sein du module Csm [SWS_Csm_00968]. L'interface est mise à disposition via l'en-tête Csm.h [SWS_Csm_00968]. Comme paramètres, la fonction prend l'identifiant du job à interrompre via job (de type uint32) ainsi que le paramètre mode (de type Crypto_OperationModeType), qui n'est pas utilisé et sert exclusivement à la compatibilité de l'interface [SWS_Csm_00968].

Valeurs de retour et comportement d'annulation

Le résultat de l'appel d'interruption est signalé de manière synchrone via la valeur de retour de type Std_ReturnType [SWS_Csm_00968] :

• E_OK : L'interruption a immédiatement réussi ; le job a été retiré de toutes les files d'attente et potentiellement directement du matériel du pilote cryptographique [SWS_Csm_00968].
• E_NOT_OK : La demande d'interruption a échoué [SWS_Csm_00968].
• CRYPTO_E_JOB_CANCELED : Une annulation immédiate n'a pas été possible ; l'interruption sera effectuée lors de la prochaine étape de traitement appropriée, puis communiquée via le callback de fin négatif du job [SWS_Csm_00968].

Concurrence et restrictions

La spécification définit Csm_CancelJob comme synchrone et non réentrante (Non Reentrant) [SWS_Csm_00968]. Les composants appelants doivent donc s'assurer qu'aucun appel concurrent de la fonction n'a lieu.

L'interface synchrone Csm_CallbackNotification est déclarée via le fichier d'en-tête Csm.h et sert à la couche sous-jacente (CRYIF) de fonction de notification pour avertir le Crypto Service Manager (CSM) de l'achèvement d'un job cryptographique [SWS_Csm_00970]. La fonction ne possède pas de valeur de retour et accepte deux paramètres d'entrée : le pointeur job vers le job terminé de type Crypto_JobType* ainsi que result de type Crypto_ResultType, qui transmet le résultat d'exécution de l'opération cryptographique sous-jacente [SWS_Csm_00970].

En ce qui concerne la concurrence, l'exécution de Csm_CallbackNotification est spécifiée comme réentrante [SWS_Csm_00970]. Les codes de retour spécifiques ou les messages d'erreur DET ou DEM distincts ne sont pas définis dans l'élément ; les états d'erreur et les résultats d'exécution du traitement cryptographique sont plutôt directement fournis via l'argument transmis result [SWS_Csm_00970].

Dans le cadre de l'interaction, la fonction vérifie le mode de traitement du job : si le bit CRYPTO_OPERATIONMODE_FINISH est positionné dans le champ job->jobPrimitiveInputOutput.mode, la spécification Csm_CallbackNotification impose d'appeler la fonction de rappel configurée [SWS_Csm_01044]. Interprétation : cet appel devrait concerner la notification de la couche d'application de niveau supérieur, puisque le flag FINISH signale l'achèvement final d'une séquence d'opérations cryptographiques. Question Q-32da2433b15ba3a9 (ouverte)

Utilisation

La fonction Csm_MainFunction est appelée cycliquement pour traiter les jobs cryptographiques demandés [SWS_Csm_00479]. Elle ne possède pas de paramètres d'entrée (void) et ne renvoie aucune valeur de retour [SWS_Csm_00479]. La déclaration est disponible via l'en-tête SchM_Csm.h [SWS_Csm_00479].

Rôles et interaction

Dans le cadre de son exécution périodique, la fonction vérifie la présence de jobs en attente dans les files d'attente internes et les transmet à la couche sous-jacente CRYIF [SWS_Csm_00479].

Instanciation et contexte d'appel

Une fonction dédiée de la forme Csm_MainFunction_<shortName> est implémentée par instance configurée, où <shortName> correspond au nom court (short name) du conteneur de configuration dans la configuration de l'ECU [SWS_Csm_00479]. L'appel cyclique devrait être effectué comme prévu par l'ordonnanceur BSW (SchM) dans une tâche périodique, puisque l'interface est mise à disposition via SchM_Csm.h. Question Q-ffb62942b1f517b3 (ouverte)

Gestion des erreurs et conditions limites

Les codes d'erreur spécifiques, les messages DET ou DEM ainsi que les exigences explicites de réentrance ne sont pas décrits dans le présent extrait de spécification [SWS_Csm_00479].

La fonction de rappel configurable <Csm_ Application Callback Notification> sert à informer de manière synchrone une application, par le Crypto Service Manager (CSM), de la fin d'un travail de traitement [SWS_Csm_00971]. L'identifiant de la fonction n'est pas prédéfini de manière fixe, mais est défini de manière spécifique au projet via le paramètre de configuration {Csm Job/ Csm Job Primitive Callback Ref}/Csm Callback Func [SWS_Csm_00971]. L'interface possède le Service-ID 0x82 et est mise à disposition via le fichier d'en-tête Csm.h [SWS_Csm_00971].

La signature ne possède aucune valeur de retour (void) et transmet deux paramètres d'entrée à l'application pour évaluation [SWS_Csm_00971] :

• jobId (uint32) : désigne l'ID unique du travail cryptographique dont l'achèvement a déclenché le callback [SWS_Csm_00971].
• result (Crypto_ResultType) : transmet le résultat ou l'état de l'opération cryptographique exécutée [SWS_Csm_00971].

Concernant la concurrence, la fonction de notification est spécifiée comme réentrante [SWS_Csm_00971]. Aucun code d'erreur DET ou DEM spécifique n'est défini pour le callback lui-même ; les erreurs survenues lors de l'opération précédente doivent être évaluées directement via result [SWS_Csm_00971]. Étant donné que l'interface est déclarée réentrante, l'implémentation côté application devrait devoir être conçue de manière à pouvoir traiter de façon sûre au niveau des threads (thread-safe) des notifications simultanées pour différents travaux. Question Q-79504ea3461f8d61 (ouverte)

Le type énuméré Crypto_AlgorithmModeType spécifie selon [SWS_Csm_01048] le mode de fonctionnement d'un algorithme cryptographique. Il est disponible via le fichier d'en-tête Crypto_GeneralTypes.h et sert à la configuration standardisée ainsi qu'à la sélection au moment de l'exécution des procédés cryptographiques dans le Crypto Service Manager.

Utilisation et plage de valeurs :

• Modes classiques de chiffrement par bloc : sont notamment pris en charge CRYPTO_ALGOMODE_ECB, CRYPTO_ALGOMODE_CBC, CRYPTO_ALGOMODE_CFB, CRYPTO_ALGOMODE_OFB, CRYPTO_ALGOMODE_CTR, CRYPTO_ALGOMODE_GCM ainsi que CRYPTO_ALGOMODE_XTS [SWS_Csm_01048].
• Procédés asymétriques et remplissage (padding) : des modes pour le chiffrement et les signatures tels que CRYPTO_ALGOMODE_RSAES_OAEP, CRYPTO_ALGOMODE_RSAES_PKCS1_v1_5, CRYPTO_ALGOMODE_RSASSA_PSS et CRYPTO_ALGOMODE_RSASSA_PKCS1_v1_5 [SWS_Csm_01048] sont inclus.
• Autres modes de fonctionnement : la plage de valeurs comprend des nombres de tours (CRYPTO_ALGOMODE_8ROUNDS, CRYPTO_ALGOMODE_12ROUNDS, CRYPTO_ALGOMODE_20ROUNDS), des procédés MAC (CRYPTO_ALGOMODE_HMAC, CRYPTO_ALGOMODE_CMAC, CRYPTO_ALGOMODE_GMAC), des générateurs de bits aléatoires (CRYPTO_ALGOMODE_CTRDRBG), des variantes de SipHash ainsi que des définitions de courbes comme CRYPTO_ALGOMODE_PXXXR1 [SWS_Csm_01048].
• États spéciaux : CRYPTO_ALGOMODE_NOT_SET (0x00) signale une clé d'algorithme non définie, tandis que CRYPTO_ALGOMODE_CUSTOM (0xff) autorise des modes de fonctionnement spécifiques au fabricant [SWS_Csm_01048].

Interprétation : comme Crypto_AlgorithmModeType est une simple énumération, le type ne possède pas de gestion des erreurs propre via DET ou DEM et n'est soumis à aucune exigence de réentrance. Question Q-3d2e905dda6531ac (ouverte) Les vérifications d'erreurs et les restrictions relatives au contexte d'appel ne résultent que des fonctions CSM auxquelles des valeurs de ce type sont transmises en paramètre.

Utilisation et structure de Crypto_JobType

La structure Crypto_JobType regroupe toutes les données pertinentes de commande, d'état et de tampon pour l'exécution d'un ordre cryptographique dans le Crypto Service Manager et est disponible via Crypto_GeneralTypes.h [SWS_Csm_01013].

Parmi les éléments centraux de la structure figurent [SWS_Csm_01013] :

• jobId : Identifiant unique du job.
• jobState : Représente l'état d'exécution actuel du job.
• jobPrimitiveInputOutput : Renvoie aux données d'entrée et de sortie spécifiques de la primitive.
• jobPrimitiveInfo : Pointeur vers des informations supplémentaires constantes relatives à la primitive cryptographique choisie.
• jobPriority : Détermine la priorité d'exécution, une valeur plus élevée caractérisant une urgence plus importante.
• jobRedirectionInfoRef : Pointeur vers des indications optionnelles concernant la redirection de clés en tant que valeurs d'entrée et de sortie.

Interaction et relations d'interface

Les champs de structure cryptoKeyId et targetCryptoKeyId référencent les clés à utiliser dans le pilote cryptographique ; conformément à la spécification, ces identifiants sont décrits par le Crypto Interface [SWS_Csm_01013]. Interprétation : jobPriority devrait régir l'ordre lors de la planification et du traitement d'ordres concurrents dans les files d'attente. Question Q-439432c5631948fb (ouverte)

Le type énumération Crypto_JobStateType définit l'état de traitement actuel d'un job cryptographique dans le CSM [SWS_Csm_01028]. Il est fourni via le fichier d'en-tête Crypto_GeneralTypes.h et fait la distinction entre deux états principaux du cycle de vie du job [SWS_Csm_01028] :

• CRYPTO_JOBSTATE_IDLE (0x00) : caractérise l'état de repos du job. Cet état est adopté initialement après l'appel de Csm_Init() ou dès qu'une opération de terminaison (état « Finish ») a été achevée [SWS_Csm_01028].
• CRYPTO_JOBSTATE_ACTIVE (0x01) : indique que le job est activement en cours de traitement et que des données d'entrée ont déjà été traitées ou que des résultats intermédiaires sont disponibles. Cet état est atteint dès qu'une opération Start ou Update s'est terminée avec succès [SWS_Csm_01028].

Concernant l'utilisation et l'interaction, le type reflète la progression d'opérations cryptographiques en continu (streaming) ou en plusieurs étapes [SWS_Csm_01028]. Une transition vers CRYPTO_JOBSTATE_ACTIVE signale que le contexte cryptographique est initialisé ou conserve en continu des résultats intermédiaires, tandis que la transition vers CRYPTO_JOBSTATE_IDLE marque l'achèvement et indique que le job est disponible pour de nouvelles séquences [SWS_Csm_01028].

La structure de données Crypto_JobPrimitiveInfoType regroupe des informations complémentaires sur un job crypto et ses primitives sous-jacentes [SWS_Csm_01012]. Elle est disponible dans la pile Classic AUTOSAR via le fichier d'en-tête Crypto_GeneralTypes.h [SWS_Csm_01012].

Composants et utilisation

Selon la spécification [SWS_Csm_01012], la structure est composée des champs suivants :

• callbackId (uint32) : identifiant interne de la fonction de rappel appelée par le module CSM dès que l'exécution du service configuré est terminée [SWS_Csm_01012].
• primitiveInfo (const Crypto_PrimitiveInfoType*) : pointeur vers une structure de données contenant la configuration complémentaire de la primitive cryptographique [SWS_Csm_01012].
• cryIfKeyId (uint32) : identifiant de la clé pour l'interface cryptographique (CryIf) [SWS_Csm_01012].
• processingType (Crypto_ProcessingType) : définit le comportement d'exécution et détermine si le travail est traité de manière synchrone ou asynchrone [SWS_Csm_01012].

Contexte d'exécution et sémantique

Le champ processingType régit la sémantique synchrone ou asynchrone du traitement du travail [SWS_Csm_01012]. La fonction de rappel enregistrée via callbackId devrait surtout être pertinente en mode asynchrone afin d'informer l'appelant de la fin du service, tandis que le pointeur primitiveInfo doit référencer une configuration de primitive valide [SWS_Csm_01012]. Question Q-791dae4fb6a83f99 (ouverte)

Utilisation

La structure de données Crypto_AlgorithmInfoType détermine la configuration exacte d'un algorithme cryptographique et est mise à disposition via le fichier d'en-tête Crypto_GeneralTypes.h [SWS_Csm_01008]. Elle se compose des éléments suivants :

• family (Crypto_AlgorithmFamilyType) : la famille primaire de l'algorithme.
• secondaryFamily (Crypto_AlgorithmFamilyType) : la famille secondaire de l'algorithme.
• keyLength (uint32) : la longueur de clé à utiliser, en bits.
• mode (Crypto_AlgorithmModeType) : le mode d'opération prévu de l'algorithme.

Chaque algorithme n'exige pas l'affectation complète de tous les éléments de structure [SWS_Csm_01008]. Selon le type d'opération cryptographique, certains champs comme le mode d'opération ou une famille secondaire peuvent rester inutilisés.

Restrictions et traitement des erreurs

Conformément à [SWS_Csm_01008], seules des combinaisons valides des éléments de structure peuvent se présenter dans AUTOSAR. Les combinaisons non autorisées – par exemple des modes d'opération incompatibles ou des longueurs de clé non admises pour une famille d'algorithmes spécifique – sont interdites. La vérification de la validité de la combinaison de paramètres devrait probablement être effectuée par les outils de configuration ou lors des appels de service par le CSM. Question Q-da4984170bba173c (ouverte)

La structure Crypto_PrimitiveInfoType sert, dans le Crypto Service Manager (CSM), à fournir des métadonnées de base sur une primitive cryptographique ([SWS_Csm_01011]). Elle est déclarée via le fichier d'en-tête Crypto_GeneralTypes.h et regroupe les caractéristiques statiques de l'opération concernée ([SWS_Csm_01011]).

La structure se compose de deux éléments ([SWS_Csm_01011]) :

• service (type : const Crypto_ServiceInfoType) : détermine le service cryptographique utilisé via une énumération, par exemple un chiffrement (Encrypt) ([SWS_Csm_01011]).
• algorithm (type : const Crypto_AlgorithmInfoType) : contient les informations détaillées sur l'algorithme utilisé ([SWS_Csm_01011]).

Étant donné que les deux éléments sont typés comme const, il devrait s'agir de données de configuration ou de métadonnées protégées en écriture, définies au moment de la configuration et évaluées purement en lecture à l'exécution par les pilotes ou le CSM ([SWS_Csm_01011]). Question Q-6d53291f7fb8cfe6 (ouverte) Aucun code d'erreur spécifique, routine de traitement d'erreurs ou restriction de concurrence n'est défini pour ce type de structure de données.

Le type énuméré Crypto_OperationModeType définit, conformément à [SWS_Csm_01029], la phase de traitement à exécuter lors d'opérations cryptographiques. Ce type est structuré sous la forme d'un masque de bits dont les trois premiers bits représentent les étapes clés Start (bit 1 / 0x01), Update (bit 2 / 0x02) et Finish (bit 3 / 0x04).

Les valeurs de l'énumération permettent de piloter les différentes phases d'exécution et de cycle de vie d'un job crypto [SWS_Csm_01029] :

• CRYPTO_OPERATIONMODE_START (0x01) : initialise le job ; l'état est réinitialisé, ce qui supprime les données d'entrée antérieures ainsi que les résultats intermédiaires.
• CRYPTO_OPERATIONMODE_UPDATE (0x02) : traite les données d'entrée pour calculer des résultats intermédiaires.
• CRYPTO_OPERATIONMODE_FINISH (0x04) : finalise les calculs de l'opération cryptographique.
• CRYPTO_OPERATIONMODE_STREAMSTART (0x03) : combine Start et Update pour les scénarios de streaming.
• CRYPTO_OPERATIONMODE_SINGLECALL (0x07) : combine Start, Update et Finish pour un traitement complet en un seul appel.

En outre, ce type prend en charge la gestion de l'espace de travail (workspace) lors de déroulements interruptibles : avec CRYPTO_OPERATIONMODE_SAVE_CONTEXT (0x08), le pilote cryptographique met à disposition de l'application le contexte de workspace actuel, tandis que CRYPTO_OPERATIONMODE_RESTORE_CONTEXT (0x10) restaure un état précédemment sauvegardé dans le workspace interne du pilote [SWS_Csm_01029]. Le type est fourni via l'en-tête Rte_Csm_Type.h.

Le type énuméré Crypto_VerifyResultType définit le résultat fonctionnel d'opérations de vérification dans le module CSM [SWS_Csm_01024]. Il est fourni via le fichier d'en-tête Rte_Csm_Type.h et sert à déterminer si une comparaison cryptographique s'est terminée avec succès [SWS_Csm_01024].

Plage de valeurs et sémantique

L'énumération comprend, selon [SWS_Csm_01024], deux valeurs discrètes pour représenter l'état de comparaison :

• CRYPTO_E_VER_OK (valeur 0x00 ou 0) : le résultat de la vérification est « true », les deux éléments comparés sont donc identiques [SWS_Csm_01024].
• CRYPTO_E_VER_NOT_OK (valeur 0x01 ou 1) : le résultat de la vérification est « false », les éléments comparés ne sont pas identiques [SWS_Csm_01024].

Le type sépare l'énoncé fonctionnel sur la concordance des données de l'état d'exécution général d'une opération. En guise d'interprétation, cela signifie qu'une routine de contrôle exécutée sans erreur peut également fournir la valeur de retour CRYPTO_E_VER_NOT_OK lorsque les données diffèrent [SWS_Csm_01024].

Utilisation et restrictions

Puisque le type de données est déclaré via Rte_Csm_Type.h, il devrait surtout être utilisé comme paramètre de sortie pour les services de vérification du CSM [SWS_Csm_01024]. Question Q-067a1d2b36ffe56b (ouverte) Aucun traitement d'erreur spécifique tel que des messages DET ou DEM, ni aucune directive concernant la réentrance ou la concurrence ne sont fixés au niveau du type lui-même [SWS_Csm_01024].

Le type énumération Crypto_ResultType sert de type de retour spécifique pour les fonctions de la pile cryptographique AUTOSAR et est disponible via l'en-tête Rte_Csm_Type.h [SWS_Csm_91044]. Il étend le schéma de retour classique avec des messages d'erreur et d'état différenciés pour les opérations cryptographiques [SWS_Csm_91044].

En plus de l'état de réussite standard E_OK (0x00) et de l'erreur générale E_NOT_OK (0x01), le type définit les états d'erreur spécifiques suivants [SWS_Csm_91044] :

• États de déroulement et de ressources : CRYPTO_E_BUSY (0x02) indique un service encore occupé, CRYPTO_E_JOB_CANCELED (0x0C) l'interruption d'une commande et CRYPTO_E_ENTROPY_EXHAUSTED (0x04) une source d'entropie épuisée du générateur aléatoire [SWS_Csm_91044].
• Problèmes de clé et d'accès : sont spécifiés des refus d'accès en lecture (CRYPTO_E_KEY_READ_FAIL, 0x06) ou en écriture (CRYPTO_E_KEY_WRITE_FAIL, 0x07), des clés manquantes (CRYPTO_E_KEY_NOT_AVAILABLE, 0x08), des clés non valides (CRYPTO_E_KEY_NOT_VALID, 0x09), des tailles de clé incorrectes (CRYPTO_E_KEY_SIZE_MISMATCH, 0x0A) ainsi que des éléments de clé source non initialisés (CRYPTO_E_KEY_EMPTY, 0x0D) [SWS_Csm_91044].

Interprétation : les composants appelants devraient évaluer ces codes de retour afin de distinguer, selon la situation, les états d'attente temporaires des erreurs de configuration permanentes. Question Q-68cfedad7880908c (ouverte)

Utilisation et structure de Csm_HashDataType

Le type de données Csm_HashDataType est défini conformément à [SWS_Csm_01920] comme un tableau d'éléments du type de base uint8. Il sert de tampon de données pour le stockage des données d'entrée qui doivent être soumises à un calcul de valeur de hachage dans le Crypto Service Manager. La longueur du tableau est conçue de manière à être suffisante pour accueillir l'intégralité des données à hacher [SWS_Csm_01920].

Configuration et gestion des variantes

Le dimensionnement effectif du tableau est contrôlé via le paramètre de configuration CsmHashDataMaxLength, qui est défini sous le chemin Csm/CsmPrimitives/CsmHash/CsmHashConfig [SWS_Csm_01920]. Cela permet de s'assurer que la zone mémoire est dimensionnée de façon adaptée à la quantité maximale de données attendue pour la configuration de hachage respective.

De plus, il existe une formation de variante cryptographique selon le modèle Csm_HashDataType_{Crypto}, l'espace réservé {Crypto} étant résolu via le SHORT-NAME de la configuration de primitive respective sous Csm/CsmPrimitives [SWS_Csm_01920]. Cela permet des structures de tampon spécifiques aux primitives dans le système.

Intégration et contraintes

Le type est mis à disposition via l'en-tête Rte_Csm_Type.h [SWS_Csm_01920]. Cela devrait signifier que le type est prévu pour le transfert standardisé de données via les interfaces RTE entre les composants logiciels et le CSM. Question Q-4240a8394cdd746d (ouverte) Lors de l'affectation du tampon, les utilisateurs doivent veiller à ce que les données ne dépassent pas la limite supérieure configurée CsmHashDataMaxLength afin d'éviter tout débordement lors du calcul du hachage.

Utilisation et structure de Csm_HashResultType

Le type de données Csm_HashResultType représente un tableau d'éléments uint8 et sert de zone mémoire suffisamment dimensionnée pour stocker les données d'un résultat de hachage [SWS_Csm_00912].

La longueur concrète de tampon du tableau est configurable et est déterminée via le paramètre de configuration CsmHashResultLength sous Csm/CsmPrimitives/CsmHash/CsmHashConfig/CsmHashResultLength [SWS_Csm_00912]. La taille du type de données dépend donc directement de la longueur de sortie de l'algorithme de hachage cryptographique concerné.

La définition de type est soumise à une variation de nom selon le modèle Csm_HashResultType_{Crypto}, l'identifiant {Crypto} étant substitué par le nom court de la primitive configurée (ecuc/Csm/CsmPrimitives.SHORT-NAME) [SWS_Csm_00912].

Le type de données est mis à disposition via l'en-tête Rte_Csm_Type.h [SWS_Csm_00912]. Interprétation : en raison de sa mise à disposition via Rte_Csm_Type.h, le type devrait principalement être prévu pour être utilisé dans des composants logiciels ou au niveau des interfaces RTE comme tampon de résultat typé pour les valeurs de retour de hachage. Question Q-4ff10e08b6a5c8c0 (ouverte)

Le type de données Csm_MacGenerateDataType sert de tableau d'octets pour stocker les données d'entrée à partir desquelles un code d'authentification de message (MAC) doit être calculé [SWS_Csm_00935].

Utilisation et structure du type

L'élément est spécifié selon [SWS_Csm_00935] comme un tableau contenant des éléments du type de base uint8. Le nom du type fait l'objet d'une variation de nom cryptographique selon le schéma Csm_MacGenerateDataType_{Crypto}, où le suffixe correspond au nom court configuré de la primitive respective [SWS_Csm_00935]. Le dimensionnement du champ est déterminé statiquement par le paramètre de configuration CsmMacGenerateDataMaxLength, ce qui garantit que le tableau offre un espace mémoire suffisant pour les données à traiter [SWS_Csm_00935].

Intégration et interfaces

Le type est mis à disposition via le fichier d'en-tête Rte_Csm_Type.h et relie les structures de données à la RTE AUTOSAR [SWS_Csm_00935]. Les composants logiciels (SWC) appelants ou les modules de logiciel de base peuvent utiliser ce type pour déclarer des tampons de données typés pour les services de génération de MAC du CSM.

restrictions

La taille du champ étant configurée de manière fixe par la longueur maximale, il convient probablement de s'assurer au niveau de l'utilisateur que les données utiles ne dépassent pas cette limite, car le type statique ne prévoit pas d'adaptation dynamique de la longueur [SWS_Csm_00935]. Question Q-2010ffc7191f874a (ouverte)

Conformément à [SWS_Csm_00927], le type de données Csm_MacGenerateResultType représente un tableau d'octets (type d'élément uint8) qui sert à recevoir les données de résultat d'un code d'authentification de message (MAC) généré.

Utilisation et dimensionnement

La spécification définit le tableau comme étant suffisamment long pour stocker les données du MAC ([SWS_Csm_00927]). La taille réelle du tampon est déterminée par le paramètre de configuration CsmMacGenerateResultLength, qui est configuré sous le chemin Csm/CsmPrimitives/CsmMacGenerate/CsmMacGenerateConfig ([SWS_Csm_00927]). De plus, le type fait l'objet d'une variation cryptographique via le nom court de la primitive ({Crypto} ou ecuc/Csm/CsmPrimitives.SHORT-NAME) selon [SWS_Csm_00927].

Disponibilité et interface

Le type est mis à disposition via l'en-tête Rte_Csm_Type.h ([SWS_Csm_00927]). Cela montre qu'il est principalement conçu pour la transmission de données typées via l'interface RTE afin de fournir la valeur MAC calculée.

restrictions

Puisqu'il s'agit d'une définition de type statique, l'instanciation concrète dépend de la préconfiguration de la longueur du MAC ; aucun autre paramètre, code d'erreur ou exigence de concurrence n'est spécifié pour ce type de données lui-même ([SWS_Csm_00927]).

Le type de données Csm_MacVerifyDataType est spécifié comme un tableau d'éléments uint8 et sert de tampon pour stocker les données pour lesquelles un Message Authentication Code (MAC) doit être vérifié [SWS_Csm_00802].

Les stipulations suivantes s'appliquent à l'utilisation et à la configuration de ce type :

• Taille du tampon : la taille du tableau dépend du paramètre de configuration CsmMacVerifyDataMaxLength dans le conteneur Csm/CsmPrimitives/CsmMacVerify/CsmMacVerifyConfig. Cela garantit que le tableau est suffisamment dimensionné pour accueillir intégralement les données d'entrée à vérifier [SWS_Csm_00802].
• Variance et dénomination : la définition contient le critère de variance Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, ce qui fait que l'identifiant de type C concret est généré de manière spécifique au module sous la forme Csm_MacVerifyDataType_{Crypto} [SWS_Csm_00802].
• Intégration d'interface : le type est exporté via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_00802]. Interprétation : la mise à disposition dans cet en-tête permet de déduire que le type devrait être principalement destiné à la communication d'interface assistée par la RTE entre les composants logiciels et le CSM. Question Q-c49670b3de0ba19c (ouverte)

Les développeurs d'applications doivent tenir compte du fait que la longueur maximale des données utiles vérifiables est limitée par la configuration statique des primitives et que les données d'entrée ne doivent pas dépasser cette capacité de tampon [SWS_Csm_00802].

Utilisation et structure

Le type Csm_MacVerifyCompareType est défini selon [SWS_Csm_00803] comme un tableau d'éléments uint8. Il sert à accueillir le Message Authentication Code (MAC) à vérifier, qui doit être comparé au MAC calculé dans le cadre d'une opération cryptographique.

La mise à disposition du type s'effectue via l'en-tête Rte_Csm_Type.h pour l'interface RTE [SWS_Csm_00803]. La désignation concrète du type est soumise à une variation de nom par le biais du nom de la primitive selon le modèle Csm_MacVerifyCompareType_{Crypto}, {Crypto} étant remplacé par le nom court de la primitive (ecuc/Csm/CsmPrimitives.SHORT-NAME).

Configuration et dimensionnement

La taille du tableau se mesure conformément à [SWS_Csm_00803] d'après l'expression CsmMacVerifyCompareLength/8 issue de la configuration (ecuc(Csm/CsmPrimitives/CsmMacVerify/CsmMacVerifyConfig/CsmMacVerifyCompareLength)). Cela reflète la longueur en octets de la valeur de comparaison du MAC.

Gestion des erreurs et conditions limites

En tant que simple définition de type pour un tableau de données, Csm_MacVerifyCompareType ne possède pas de valeurs de retour propres et ne génère aucun code d'erreur direct ni événement DET/DEM. Les contraintes d'application suivantes s'appliquent toutefois :

• Mise à disposition du tampon : les appelants devraient être responsables d'initialiser entièrement le tableau avec le MAC de référence reçu avant de le transmettre à une fonction de vérification. Question Q-94b98958fd778057 (ouverte)
• Concurrence : s'agissant d'une structure de données, le type lui-même est réentrant. Des accès concurrents en lecture et en écriture de plusieurs tâches à la même instance de tableau devraient toutefois entraîner des corruptions en l'absence de synchronisation. Question Q-148c0a523da7b402 (ouverte)

Le type Csm_EncryptDataType définit un tableau d'octets composé d'éléments uint8, qui sert à recevoir les données à chiffrer [SWS_Csm_01921]. Il est mis à disposition via le fichier d'en-tête Rte_Csm_Type.h et permet aux composants logiciels de transmettre des données typées aux services cryptographiques du module [SWS_Csm_01921].

Structure et configuration

• Éléments du tableau : les éléments sont du type de base uint8 [SWS_Csm_01921].
• Taille : la longueur du tableau dépend du paramètre de configuration CsmEncryptDataMaxLength situé sous la configuration de primitive respective CsmEncryptConfig [SWS_Csm_01921].
• Variation de nom : le nom du type varie selon la primitive conformément au schéma Csm_EncryptDataType_{Crypto}, où {Crypto} correspond au nom court (SHORT-NAME) de la primitive CSM configurée [SWS_Csm_01921].

Utilisation et restrictions

En tant que pure définition de type, l'élément ne possède aucune réentrance ni gestion des erreurs propre. Étant donné que la taille du tableau est strictement liée à la taille maximale de tampon de la configuration, on peut interpréter que l'appelant devrait, lors du remplissage, veiller à ce que les données fournies ne dépassent pas la limite de tampon CsmEncryptDataMaxLength [SWS_Csm_01921]. Question Q-4bf70d603b5679d3 (ouverte)

Utilisation et finalité

Le type de données Csm_EncryptResultType est spécifié comme un tableau d'octets avec le type d'élément uint8 et sert à recevoir les données chiffrées (résultat du chiffrement) d'un processus de chiffrement ([SWS_Csm_01922]). D'après la spécification, le tableau doit être dimensionné de manière à être suffisamment long pour recevoir l'ensemble des données du texte chiffré ([SWS_Csm_01922]).

Configuration et variantes

La définition du type de données est soumise à une formation de variantes sur la base des primitives cryptographiques configurées. Pour chaque primitive, un identifiant spécifique au type est formé selon le schéma Csm_EncryptResultType_{Crypto}, où {Crypto} correspond au nom court de la primitive respective ([SWS_Csm_01922]). La taille statique du tableau est déterminée via le paramètre de configuration CsmEncryptResultMaxLength sous Csm/CsmPrimitives/CsmEncrypt/CsmEncryptConfig/ ([SWS_Csm_01922]).

Intégration et contraintes

Le type de données est exporté via le fichier d'en-tête Rte_Csm_Type.h ([SWS_Csm_01922]). Interprétation : en raison de sa mise à disposition via Rte_Csm_Type.h, le type devrait être conçu pour le transfert standardisé de données entre les composants logiciels applicatifs et le Crypto Service Manager via les ports RTE. Question Q-6dc06520e3fd9dc6 (ouverte) Lors de la mise à disposition du tampon, les utilisateurs doivent s'assurer que les résultats de chiffrement ne dépassent pas la longueur maximale configurée CsmEncryptResultMaxLength ([SWS_Csm_01922]).

Utilisation et structure des données

Dans la spécification du Crypto Service Manager, le type Csm_DecryptDataType est défini comme un tableau avec des éléments du type de base uint8 [SWS_Csm_01923]. Il sert de tampon de stockage dédié pour les données d'entrée à déchiffrer [SWS_Csm_01923]. Le dimensionnement du tableau est obligatoirement prescrit de telle sorte que sa capacité doit toujours être suffisamment longue pour accueillir intégralement les données respectives [SWS_Csm_01923].

Configuration et gestion des variantes

Le dimensionnement du tableau s'effectue statiquement via le paramètre de configuration ecuc(Csm/CsmPrimitives/CsmDecrypt/CsmDecryptConfig/CsmDecryptDataMaxLength) [SWS_Csm_01923]. De plus, le type de données fait l'objet d'une variance cryptographique selon Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME} [SWS_Csm_01923]. De ce fait, l'identifiant de type pour la configuration concrète de la primitive est instancié avec le nom court correspondant en tant que Csm_DecryptDataType_{Crypto} [SWS_Csm_01923].

Intégration et contraintes

La définition est mise à disposition pour l'ensemble du système via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_01923]. Interprétation : l'inclusion dans Rte_Csm_Type.h laisse supposer que le type est avant tout destiné aux ports typés et à l'échange de données entre les composants logiciels et le module CSM via la RTE. Question Q-6dcc31d5d7258088 (ouverte) Puisqu'il s'agit d'une structure de données et non d'une fonction, ni sémantiques d'appel synchrones ou asynchrones, ni prescriptions de réentrance ou messages d'erreur DET spécifiques ne sont définis dans le périmètre de la spécification [SWS_Csm_01923].

Conformément à [SWS_Csm_01924], le type de données Csm_DecryptResultType est défini dans le module Csm comme un tableau avec des éléments du type uint8. Il sert de tampon de données pour le stockage des données de résultat d'un texte clair déchiffré et doit être dimensionné de façon suffisante pour accueillir l'intégralité du texte clair.

D'après [SWS_Csm_01924], les stipulations suivantes s'appliquent à la configuration, à la mise à disposition et à la structuration du type :

• Disponibilité de l'en-tête : la définition du type de données est mise à disposition via le fichier d'en-tête Rte_Csm_Type.h.
• Dimensionnement du tampon : la taille du tableau est prédéfinie via le paramètre de configuration CsmDecryptResultMaxLength (chemin Csm/CsmPrimitives/CsmDecrypt/CsmDecryptConfig/CsmDecryptResultMaxLength), ce qui fixe statiquement l'espace mémoire maximal pour le résultat du déchiffrement.
• Génération de variantes cryptographiques : le nom du type est soumis à une génération de variantes de primitives selon le schéma Csm_DecryptResultType_{Crypto}, la variante effective étant contrôlée par l'élément de configuration Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}.

En ce qui concerne le contexte d'appel, la concurrence et le traitement des erreurs, [SWS_Csm_01924] contient exclusivement la définition de type, sans logique fonctionnelle propre. Interprétation : le type devrait principalement servir de structure de stockage dans les composants logiciels utilisateurs afin de recevoir les données de sortie des opérations de déchiffrement cryptographique du CSM. Question Q-54c836ed946ee1f2 (ouverte) Aucun code d'erreur DET ou DEM spécifique n'est défini pour ce type de données ; les responsables de la configuration doivent toutefois s'assurer que la longueur maximale configurée est suffisante pour tous les textes en clair à traiter.

Utilisation et définition de type

Le type de données Csm_AEADEncryptPlaintextType sert, selon [SWS_Csm_01925], de tampon de données pour le texte en clair destiné à être traité dans le cadre d'une opération de chiffrement AEAD (Authenticated Encryption with Associated Data). Le type est défini comme un tableau d'octets avec le type d'élément uint8 et offre un espace mémoire suffisant pour contenir l'intégralité du texte en clair à chiffrer.

Dimensionnement et génération de variantes

La taille concrète du tampon n'est pas prédéfinie de manière fixe, mais dépend du paramètre de configuration CsmAEADEncryptPlaintextMaxLength issu de la configuration de la primitive respective ([SWS_Csm_01925]). De plus, le type est soumis à une variation de nom et de structure : selon la primitive cryptographique configurée, l'identifiant est complété par le nom court de la primitive (Csm_AEADEncryptPlaintextType_{Crypto}).

Intégration et interface

Selon [SWS_Csm_01925], le type est mis à disposition via l'en-tête Rte_Csm_Type.h. Cela appuie l'interprétation selon laquelle le type est principalement mis à la disposition des composants logiciels d'application dans le contexte de la RTE AUTOSAR, afin de transmettre des données de texte en clair typées aux services cryptographiques du CSM. Comme il s'agit d'une simple déclaration de type, la spécification ne définit aucun code d'erreur propre ni aucune exigence de réentrance au niveau du type de données.

Le type de données Csm_AEADEncryptAssociatedDataType définit un tableau d'octets composé d'éléments du type de base uint8, qui sert de tampon pour recevoir les données d'en-tête ou les données associées lors des opérations de chiffrement AEAD [SWS_Csm_01928]. Le type est fourni via le fichier d'en-tête Rte_Csm_Type.h et permet l'échange de données typées via l'interface AUTOSAR-RTE du Crypto Service Manager [SWS_Csm_01928].

Le dimensionnement et la forme du type dépendent de la configuration de la primitive cryptographique [SWS_Csm_01928] :

• Taille du tableau : la taille du tampon est mesurée en fonction du paramètre de configuration CsmAEADEncryptAssociatedDataMaxLength au sein de la configuration Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig, ce qui garantit que le tableau est suffisamment long pour les données d'en-tête [SWS_Csm_01928].
• Variation de nom : l'élément est soumis à une variation de nom spécifique à la cryptographie Csm_AEADEncryptAssociatedDataType_{Crypto}, où le paramètre fictif {Crypto} correspond au nom court de la primitive respective issue de CsmPrimitives.SHORT-NAME [SWS_Csm_01928].

Les appelants doivent s'assurer, lors de l'affectation du tableau, que la longueur réelle des données d'en-tête à transmettre ne dépasse pas la taille maximale configurée [SWS_Csm_01928]. Interprétation : étant donné que les données associées dans les procédés AEAD restent non chiffrées mais sont authentifiées, le type de données devrait principalement servir à transmettre de manière cohérente des métadonnées spécifiques au protocole entre l'application et le CSM. Question Q-26b724044c51253f (ouverte)

Le type de données Csm_AEADEncryptCiphertextType sert, selon [SWS_Csm_01927], de tableau d'octets pour stocker les données chiffrées lors des opérations de chiffrement cryptographique AEAD dans le module Classic AUTOSAR Csm.

La spécification définit l'élément de données comme un tableau composé d'éléments du type de base uint8 [SWS_Csm_01927]. La taille de tampon fixe est déterminée par le paramètre de configuration CsmAEADEncryptCiphertextMaxLength au sein du chemin de configuration Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig [SWS_Csm_01927]. Conformément à l'exigence, le tableau doit être dimensionné suffisamment grand pour accueillir la totalité des données chiffrées [SWS_Csm_01927].

L'identifiant de type présente une variation de nom dépendante de la primitive : via l'attribut de configuration Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, le nom de type concret est développé en Csm_AEADEncryptCiphertextType_{Crypto} [SWS_Csm_01927]. Cette définition est mise à disposition des composants logiciels d'application ainsi que du CSM via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_01927].

En pratique, les composants appelants devraient déclarer des tampons appropriés pour recevoir les résultats de chiffrement d'une opération AEAD. Question Q-af095525ea319451 (ouverte) Aucun contexte d'appel spécifique, traitement d'erreurs (tel que DET ou DEM), valeur de retour ou consigne de réentrance n'est défini dans les sources pour cette structure de données.

Le type de données Csm_AEADEncryptTagType définit, selon [SWS_Csm_01926], un tableau d'octets (type d'élément uint8) qui sert de tampon pour les données de la balise d'authentification lors des opérations de chiffrement AEAD. Conformément à la spécification, le tableau est dimensionné avec une longueur suffisante pour accueillir l'intégralité des données de la balise [SWS_Csm_01926].

Concernant la structure et la configuration, les dispositions suivantes issues de [SWS_Csm_01926] s'appliquent :

• Taille du tampon : le dimensionnement du tableau est défini via le paramètre de configuration CsmAEADEncryptTagLength sous Csm/CsmPrimitives/CsmAEADEncrypt/CsmAEADEncryptConfig [SWS_Csm_01926].
• Variante de nom : le nom du type présente une variance cryptographique et est formé selon le schéma Csm_AEADEncryptTagType_{Crypto}, où {Crypto} correspond au nom court de la primitive respective (SHORT-NAME) [SWS_Csm_01926].
• Inclusion de l'en-tête : le type est fourni via l'en-tête Rte_Csm_Type.h [SWS_Csm_01926].

En raison de sa disponibilité dans Rte_Csm_Type.h, le type de données devrait être destiné à des interfaces logicielles standardisées (interprétation : utilisation pour le passage de tampons dans les ports de composants logiciels) [SWS_Csm_01926]. Question Q-3cd2f6ae1229483e (ouverte)

Utilisation et structure

Le type de données Csm_AEADDecryptCiphertextType définit, conformément à [SWS_Csm_00922], un tableau d'octets basé sur le type d'élément uint8. Il sert de tampon suffisamment dimensionné pour accueillir le texte chiffré devant être déchiffré dans le cadre d'une opération AEAD (Authenticated Encryption with Associated Data) [SWS_Csm_00922]. La mise à disposition de la définition de type s'effectue via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_00922].

Dimensionnement et variance

Le dimensionnement du champ s'effectue statiquement sur la base du paramètre de configuration CsmAEADDecryptCiphertextMaxLength au sein de la branche de configuration Csm/CsmAEADDecrypt/CsmAEADDecryptConfig [SWS_Csm_00922]. Le tableau est conçu de manière à pouvoir contenir l'intégralité du texte chiffré à traiter. En outre, le nom du type est soumis à une variance cryptographique selon le modèle Csm_AEADDecryptCiphertextType_{Crypto}, la partie identifiant {Crypto} étant formée par le nom court de la primitive respective (CsmPrimitives.SHORT-NAME) [SWS_Csm_00922].

Interaction et conditions aux limites

En raison de sa définition dans Rte_Csm_Type.h, le type devrait être principalement prévu pour la connexion typée de composants logiciels (SW-Cs) via des ports RTE à la passerelle de service crypto ou au CSM [SWS_Csm_00922]. Question Q-35738ff5fc96c699 (ouverte) Étant donné que la taille du tableau est fixée au moment de la configuration, les appelants doivent s'assurer que les données de texte chiffré ne dépassent pas la longueur maximale, afin d'exclure tout dépassement de tampon à l'exécution.

Le type de données Csm_AEADDecryptAssociatedDataType est défini comme un tableau d'éléments du type uint8 et suit le modèle de nom dépendant de la configuration Csm_AEADDecryptAssociatedDataType_{Crypto} [SWS_Csm_00923]. Ce type de données a pour but de fournir une zone mémoire d'une taille suffisante pour accueillir les données d'en-tête ou les données associées (Associated Data) d'un déchiffrement authentifié (AEAD Decrypt) [SWS_Csm_00923].

La taille du tableau dépend du paramètre de configuration CsmAEADDecryptAssociatedDataMaxLength dans le chemin de configuration Csm/CsmAEADDecrypt/CsmAEADDecryptConfig [SWS_Csm_00923]. Par le biais de la variance Crypto={ecuc/Csm/CsmPrimitives.SHORT-NAME}, l'identifiant de type pour la primitive respective configurée dans le Crypto Service Manager est spécialisé au moyen de son nom court [SWS_Csm_00923]. Ainsi, un tampon spécifique avec une longueur maximale adaptée peut être déclaré pour chaque primitive cryptographique.

Le type de données est exporté via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_00923]. Comme il s'agit d'une simple définition de type, l'entrée ne spécifie aucun code d'erreur, message DET ou condition de réentrance. En guise d'interprétation, le tableau devrait servir de tampon de données typé pour la transmission, entre les composants logiciels et le CSM via la RTE, de données annexes non chiffrées mais à vérifier cryptographiquement. Question Q-2f32bbe9a4489b27 (ouverte)

Utilisation et finalité

Le type de données Csm_AEADDecryptTagType est défini comme un tableau d'octets avec le type d'élément uint8 et sert de zone mémoire dédiée pour recevoir les données de tag lors d'opérations de déchiffrement AEAD [SWS_Csm_01074]. La mise à disposition s'effectue via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_01074].

Dimensionnement et dépendance vis-à-vis de la configuration

Le dimensionnement du tableau est configurable et dépend de la longueur de tag configurée CsmAEADDecryptTagLength [SWS_Csm_01074]. Le nombre d'éléments est déterminé par l'expression (({ecuc(Csm/CsmPrimitives/CsmAEADDecrypt/CsmAEADDecryptConfig/CsmAEADDecryptTagLength)}+7)/8) [SWS_Csm_01074]. Grâce à ce calcul, la longueur du tag spécifiée en bits est convertie en octets complets, les longueurs en bits non divisibles par huit étant arrondies à la limite d'octet supérieure.

Le type fait l'objet d'une variation de nom selon le schéma Csm_AEADDecryptTagType_{Crypto}, où {Crypto} est remplacé par le nom court (SHORT-NAME) de la configuration de primitive respective [SWS_Csm_01074]. Ainsi, une structure typée de manière appropriée existe pour chaque instance de primitive de déchiffrement AEAD configurée.

Conditions d'intégration et contraintes

La mise à disposition via Rte_Csm_Type.h devrait signifier que ce type est avant tout destiné aux composants logiciels au niveau des ports de la RTE AUTOSAR, afin de transmettre le tag d'authentification au Crypto Service Manager [SWS_Csm_01074]. Question Q-2a0bebbb8e1d6b76 (ouverte) Le type n'apportant pas ses propres flux de contrôle ni mécanismes de synchronisation, la cohérence des données dans le tampon est probablement entièrement garantie par le contexte appelant pendant le cycle de déchiffrement.

Utilisation et structure

Le type de données Csm_AEADDecryptPlaintextType ou sa variante spécifique à la primitive Csm_AEADDecryptPlaintextType_{Crypto} est défini comme un tableau d'octets avec des éléments du type uint8 [SWS_Csm_01075]. Il sert à fournir un tampon suffisamment dimensionné pour le stockage des données en texte clair lors d'un déchiffrement AEAD (Authenticated Encryption with Associated Data) [SWS_Csm_01075]. La taille fixe du tableau est déterminée par le paramètre de configuration CsmAEADDecryptPlaintextMaxLength au sein de la configuration de la primitive de déchiffrement AEAD respective [SWS_Csm_01075]. Le type de données est mis à disposition des composants logiciels via l'en-tête Rte_Csm_Type.h, le nom du type étant lié au nom court des primitives CSM configurées via la variation Crypto [SWS_Csm_01075].

Gestion des erreurs et concurrence

Puisqu'il s'agit d'une pure définition de type, l'élément ne définit aucun code d'erreur, valeur de retour ou notification DET propre [SWS_Csm_01075]. La principale contrainte fonctionnelle réside dans la longueur maximale définie statiquement : les données en texte clair qui dépassent la limite configurée ne peuvent pas être représentées dans ce tampon [SWS_Csm_01075]. Interprétation : le type devrait principalement servir au transfert typé de données via les ports RTE lorsque les SWC reçoivent de manière asynchrone ou synchrone les résultats des services de déchiffrement. Question Q-2de04243d7f996c8 (ouverte) Les appelants doivent probablement s'assurer eux-mêmes que les limites du tampon sont respectées et que les accès simultanés en écriture ou en lecture sur plusieurs tâches sont synchronisés de manière sûre au niveau des threads.

Selon [SWS_Csm_01083], le type Csm_SignatureGenerateDataType définit un tableau d'éléments uint8 servant de tampon pour recevoir les données à partir desquelles une signature cryptographique doit être générée. Le nommage concret dans le code source est spécifique à la primitive et suit le modèle Csm_SignatureGenerateDataType_{Crypto}, l'identifiant variant en fonction du nom court de la primitive cryptographique configurée [SWS_Csm_01083].

Le dimensionnement statique du tableau de données est déterminé via le paramètre de configuration CsmSignatureGenerateDataMaxLength [SWS_Csm_01083]. Le type de données est mis à disposition via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_01083]. Interprétation : en raison de sa mise à disposition via Rte_Csm_Type.h, le type de tableau devrait être principalement prévu pour le transfert typé de données sur les ports RTE entre les composants logiciels et le module CSM. Question Q-dcc731a5b8961aef (ouverte)

Lors de la configuration et de l'utilisation, il convient de noter que CsmSignatureGenerateDataMaxLength définit la limite supérieure fixe du tableau [SWS_Csm_01083]. Les utilisateurs doivent s'assurer par configuration que la taille du tampon est suffisante pour toutes les données d'entrée de la génération de signature survenant en fonctionnement, étant donné que le tableau est alloué statiquement.

Conformément à [SWS_Csm_01077], le type de données Csm_SignatureGenerateResultType définit un tableau d'octets basé sur uint8, qui sert à recevoir une signature cryptographique générée ainsi que l'indication de sa longueur. Le type est déclaré via l'en-tête Rte_Csm_Type.h et fournit le tampon de sortie standardisé pour les opérations de signature dans le Crypto Service Manager.

La structure et le dimensionnement du type sont configurables :

• Taille du tampon : le nombre d'éléments uint8 est prédéfini via le paramètre de configuration CsmSignatureGenerateResultLength de la configuration respective de génération de signature ([SWS_Csm_01077]).
• Variante de nom : l'identifiant contient le suffixe _{Crypto}, qui correspond au nom court de la primitive configurée ([SWS_Csm_01077]).

Puisqu'il s'agit d'une pure définition de type, [SWS_Csm_01077] ne contient aucune spécification de codes d'erreur, de notifications DET ou de propriétés de réentrance. La sémantique d'exécution et le passage de tampon devraient dépendre des conventions d'appel synchrones ou asynchrones des interfaces de service CSM. Question Q-3304c06a29f069a2 (ouverte) Les appelants doivent s'assurer que la taille de tableau configurée est toujours suffisante pour la signature à accueillir, valeur de longueur comprise.

Le type de données Csm_SignatureVerifyDataType est défini selon [SWS_Csm_01078] comme un tableau d'octets avec le type d'élément uint8 et sert à la mise en mémoire tampon des données dont la signature doit être vérifiée.

Conformément à [SWS_Csm_01078], les stipulations suivantes s'appliquent à la configuration et à l'utilisation du type :

• Dimensionnement du tableau : la taille du tableau correspond à la valeur de configuration CsmSignatureVerifyDataMaxLength issue du chemin de configuration Csm/CsmPrimitives/CsmSignatureVerify/CsmSignatureVerifyConfig, de sorte que le tableau soit suffisamment dimensionné pour accueillir l'ensemble des données à vérifier.
• Variation de nom : le nom du type varie selon la primitive cryptographique respective selon le schéma Csm_SignatureVerifyDataType_{Crypto}, {Crypto} correspondant au nom court CsmPrimitives.SHORT-NAME.
• Mise à disposition de l'en-tête : la définition de type est disponible via le fichier d'en-tête Rte_Csm_Type.h.

Interprétation : en raison de sa mise à disposition dans Rte_Csm_Type.h, le type devrait avant tout être destiné aux composants logiciels à l'interface RTE afin de transmettre au Crypto Service Manager des données utiles jusqu'à concurrence de la longueur maximale configurée pour la vérification de signature [SWS_Csm_01078]. Question Q-c1541703c2bcd199 (ouverte)

Le type Csm_SignatureVerifyCompareType définit un tableau d'octets basé sur uint8 qui fournit suffisamment d'espace mémoire pour une signature cryptographique à vérifier ([SWS_Csm_01079]). Il est mis à disposition via l'en-tête Rte_Csm_Type.h et permet aux composants logiciels d'accéder de manière typée aux données de comparaison de signature ([SWS_Csm_01079]).

Configuration et variance

La taille concrète du tableau n'est pas fixe, mais dépend de la valeur de configuration CsmSignatureVerifyCompareLength issue de la configuration de vérification de signature de la primitive respective ([SWS_Csm_01079]). De plus, le type fait l'objet d'une variation de nom via le nom court de la primitive cryptographique (Crypto = {ecuc/Csm/CsmPrimitives.SHORT-NAME}), de sorte que l'identifiant typé est formé sous la forme Csm_SignatureVerifyCompareType_{Crypto} ([SWS_Csm_01079]).

Aspects d'utilisation et contraintes

• Contexte d'appel et sémantique : en tant que pure structure de données, l'élément ne possède aucune sémantique synchrone ou asynchrone autonome. L'instanciation est généralement effectuée par l'appelant des services de vérification du module ([SWS_Csm_01079]).
• Gestion des erreurs : la définition de type ne définit aucun code d'erreur ni message DET/DEM propre ([SWS_Csm_01079]). Interprétation : une validation de la longueur du tampon ou de l'intégrité du pointeur devrait avoir lieu dans les fonctions CSM utilisatrices. Question Q-60454c8a7d8035cf (ouverte)
• Concurrence : pour les pures définitions de type, il n'existe aucune restriction quant à la réentrance ; l'accès concurrent aux instances de tampon doit être coordonné par les modules utilisateurs ([SWS_Csm_01079]).

Utilisation et finalité

Le type de données Csm_RandomGenerateResultType est défini comme un tableau et sert de zone mémoire structurée pour enregistrer les données de résultat d'un nombre aléatoire généré [SWS_Csm_00930]. Les différents éléments du tableau possèdent le type de base uint8, ce qui permet de représenter le nombre aléatoire résultant sous la forme d'une séquence d'octets contiguë [SWS_Csm_00930].

Configuration et gestion des variantes

La taille du tampon n'est pas transmise de manière dynamique, mais déterminée statiquement via la configuration du module : le nombre d'éléments du tableau dépend du paramètre de configuration CsmRandomGenerateResultLength sous le chemin Csm/CsmPrimitives/CsmRandomGenerate/CsmRandomGenerateConfig [SWS_Csm_00930]. De plus, l'identifiant fait l'objet d'une variation de nom spécifique à la cryptographie selon le schéma Csm_RandomGenerateResultType_{Crypto}, où le suffixe correspond au nom court de la primitive respective [SWS_Csm_00930]. De cette manière, chaque instance configurée de la génération aléatoire reçoit un tampon conforme au type et de longueur appropriée.

Intégration et contraintes

La déclaration du type est fournie via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_00930]. Interprétation : étant donné que la mise à disposition s'effectue via l'en-tête RTE, ce type de données devrait principalement être destiné aux composants logiciels d'application (Application Software Components) pour recevoir des valeurs aléatoires via des ports de manière sécurisée du point de vue des types. Question Q-ea993612037bec12 (ouverte) Les contextes d'appel d'API concrets, les codes d'erreur ou les aspects de concurrence ne sont pas rattachés au type lui-même, mais aux services CSM associés, tandis que ce type garantit le besoin de mémoire statique [SWS_Csm_00930].

Utilisation et sémantique

Le type Csm_VerifyResultPtr est un AUTOSAR-Implementation-Data-Type de la catégorie DATA_REFERENCE, dont la cible de pointeur est Csm_VerifyResultType (formellement Csm_VerifyResultType*) [SWS_Csm_91046]. La définition de type est mise à disposition via l'en-tête Rte_Csm_Type.h et est ainsi disponible pour les composants d'application via la RTE ainsi que pour les modules du logiciel de base [SWS_Csm_91046].

Le rôle fonctionnel de Csm_VerifyResultPtr consiste à renvoyer le résultat de vérification lors d'opérations cryptographiques asynchrones [SWS_Csm_91046]. En cas d'exécution asynchrone, le pointeur référence un tampon réservé par l'appelant, dans lequel le module Csm inscrit le résultat une fois la vérification terminée [SWS_Csm_91046].

Concurrence et restrictions

Comme Csm_VerifyResultPtr est explicitement prévu pour le retour asynchrone [SWS_Csm_91046], les utilisateurs doivent s'assurer que la validité de l'objet cible référencé est préservée pendant toute la durée de l'opération. Les aspects suivants doivent être pris en compte :

• La zone mémoire référencée de type Csm_VerifyResultType devrait devoir rester valide et protégée pendant toute la durée de l'exécution asynchrone jusqu'à l'arrivée du retour (interprétation : prévention des accès en écriture à des adresses mémoire non valides). Question (ouverte)
• Les appelants ne devraient vraisemblablement pas faire pointer le pointeur vers des variables volatiles sur la pile si la fonction appelante peut déjà être quittée avant la fin du travail asynchrone. Question (ouverte)

Le type énumération Crypto_KeyStatusType définit l'état de validité des clés cryptographiques et est mis à disposition via le fichier d'en-tête Rte_Csm_Type.h [SWS_Csm_91102].

Plage de valeurs et sémantique

Le type comprend deux valeurs [SWS_Csm_91102] :

• CRYPTO_KEYSTATUS_INVALID (0x00) : l'état de la clé est non valide. Cela se produit par exemple lorsque, après la définition d'un élément de clé au moyen de Csm_KeyElementSet, la fonction Csm_KeySetValid n'a pas encore été exécutée.
• CRYPTO_KEYSTATUS_VALID (0x01) : la clé est valide, une fois que l'état a été défini, par exemple, par l'appel réussi de Csm_KeySetValid.

Conditions d'ordonnancement et interaction

La logique d'état associe directement la validité aux processus de mise à jour de la gestion des clés : chaque modification d'éléments de clé place la clé dans un état intermédiaire non valide, qui ne prend fin qu'avec la validation explicite via Csm_KeySetValid [SWS_Csm_91102]. Interprétation : les appelants et les services cryptographiques devraient donc exiger l'état CRYPTO_KEYSTATUS_VALID avant l'exécution d'opérations cryptographiques afin d'exclure tout dysfonctionnement dû à des données de clé incomplètes. Question Q-7ad50e0568814efa (ouverte)