classe ara::crypto::cryp::WriteableKeySlot

L'interface ara::crypto::cryp::WriteableKeySlot sert dans AUTOSAR Adaptive d'abstraction accessible en écriture pour les emplacements de stockage de clés dans un CryptoProvider. Les instances ne peuvent être ni copiées ni déplacées ([SWS_CRYPT_50170], [SWS_CRYPT_50168]), mais sont référencées via le type de pointeur intelligent Sptr [SWS_CRYPT_50172]. Le contenu de l'emplacement de clé est purgé via la méthode sûre pour les threads Clear(), une sémantique de rollback s'appliquant en cas d'erreur telle que kBusyResource ou kUnsupported [SWS_CRYPT_30405].

plus ›

Contexte

L'interface ara::crypto::cryp::WriteableKeySlot définit, au sein de l'AUTOSAR Adaptive Platform, un emplacement de stockage inscriptible pour les clés cryptographiques dans le contexte d'un fournisseur crypto (Crypto Provider). Elle dérive directement de l'interface de base KeySlot et constitue une abstraction standardisée permettant d'effacer de manière ciblée des emplacements de clé gérés et de contrôler leur cycle de vie. Les applications de la pile crypto font office de partenaires d'interaction essentiels en tant que consommateurs, tout comme le fournisseur crypto concret, qui gère la liaison vers le stockage de clés physique ou logique. La création d'instances concrètes devrait s'effectuer au moyen de méthodes de fabrique ou de fournisseur de niveau supérieur, dans la mesure où l'interface fait office de classe de base purement abstraite. Question Q-5c3b13bb35c3ff53 (ouverte)

Cycle de vie

Le modèle de ressources et de propriété de ara::crypto::cryp::WriteableKeySlot empêche strictement la duplication de références de clé via la sémantique de valeur. À cette fin, le constructeur de copie [SWS_CRYPT_50170] ainsi que le constructeur de déplacement [SWS_CRYPT_50171] sont tous deux explicitement supprimés (=delete). De la même manière, les déclarations supprimées de l'opérateur d'assignation par copie [SWS_CRYPT_50168] et de l'opérateur d'assignation par déplacement [SWS_CRYPT_50169] interdisent toute assignation ultérieure.

La transmission référentielle et la gestion partagée s'effectuent à la place via l'alias de type de pointeur intelligent défini Sptr, qui est concrétisé sous forme de std::shared_ptr<WriteableKeySlot> [SWS_CRYPT_50172]. La destruction de l'instance est sécurisée par un destructeur par défaut virtuel, qui est spécifié comme sûr vis-à-vis des exceptions (exception safe) et n'émet aucune exception (noexcept=default) [SWS_CRYPT_50167]. Cela permet la libération polymorphe sûre via des pointeurs vers l'interface. Sur le plan de l'état, un emplacement peut être occupé ou vide. L'occupation de l'emplacement devrait avoir lieu via des interfaces distinctes du fournisseur crypto, tandis que le vidage est réalisé via la méthode thread-safe Clear() [SWS_CRYPT_30405]. Question Q-72dfcb17eb3e2d25 (ouverte)

Diagramme d'états : Transitions d'état du contenu de clé par Clear() et traitement des erreurs. Sources : [SWS_CRYPT_30405]

Parcours d'utilisation

Le chemin d'utilisation central se concentre sur la réinitialisation ou l'effacement contrôlé du matériel de clé stocké :

• Référencement : L'appelant accède à l'instance via un pointeur partagé du type WriteableKeySlot::Sptr [SWS_CRYPT_50172].
• Appel d'effacement : L'appel de la méthode virtuelle pure Clear() déclenche le processus d'effacement pour le contenu actuel de l'emplacement de clé [SWS_CRYPT_30405]. La méthode étant thread-safe, l'appel peut également avoir lieu dans des contextes concurrents [SWS_CRYPT_30405].
• Vérification du résultat : L'opération renvoie un ara::core::Result<void> [SWS_CRYPT_30405]. Si l'emplacement de clé était déjà vide auparavant ou si le contenu a été supprimé sans erreur, le résultat représente un état de succès avec une valeur vide [SWS_CRYPT_30405].

Scénarios d'erreur

La méthode Clear() est déclarée sûre vis-à-vis des exceptions et noexcept ; les situations d'erreur sont transportées via ara::core::Result conformément au modèle d'erreur d'AUTOSAR Adaptive [SWS_CRYPT_30405]. Les codes d'erreur possibles comprennent :

• ara::crypto::CryptoErrc::kUnsupported : Se produit lorsque la réalisation concrète de l'emplacement de clé ne prend pas en charge l'effacement [SWS_CRYPT_30405]. Pour ce cas, l'interface garantit une sémantique de retour arrière (rollback), de sorte que l'état reste inchangé [SWS_CRYPT_30405].
• ara::crypto::CryptoErrc::kBusyResource : Est renvoyé si l'opération d'effacement ne peut temporairement pas être exécutée [SWS_CRYPT_30405]. Cela devrait typiquement être causé par des accès concurrents à des ressources de stockage liées au matériel. Question (ouverte) Ici aussi, une sémantique de retour arrière garantit qu'aucune modification partielle ne subsiste [SWS_CRYPT_30405].