module ara::crypto — Cryptography

Le cluster fonctionnel Cryptography fournit des services de sécurité standardisés pour le chiffrement symétrique et asymétrique, la vérification de signature ainsi que la gestion sécurisée des clés et des certificats (PlatformDesign p. 71). L'accès aux opérations cryptographiques et aux emplacements de clé persistants s'effectue de manière strictement isolée via des fournisseurs spécifiques à la plateforme et des spécificateurs d'instance déclarés dans le manifeste (SWS Cryptography p. 39). L'application des restrictions d'utilisation empêche toute compromission du matériel de clé sensible ([SWS_CRYPT_50092]).

plus ›

Le cluster fonctionnel Cryptography (ara::crypto) fournit une architecture de sécurité complète pour l'AUTOSAR Adaptive Platform (PlatformDesign p. 71). Pour se prémunir contre la compromission d'applications utilisateur, la conservation des clés et l'exécution cryptographique sont généralement encapsulées dans un démon de plateforme isolé ou un module matériel de sécurité (HSM) (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87). La fonctionnalité globale se divise en CryptoProvider spécialisés pour les primitives de calcul, l'espace de stockage de clés pour les emplacements de clés persistants (KeySlots) ainsi qu'un X509Provider à l'échelle de la machine pour la gestion des certificats PKI (SWS Cryptography p. 39).

Diagramme de contexte : relations d'architecture et de composants du cluster fonctionnel Cryptography entre application, démon et fournisseurs. Sources : SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Les applications créent des contextes cryptographiques tels que des chiffrements symétriques ([SWS_CRYPT_20742]), des chiffrements authentifiés ([SWS_CRYPT_20745]), des fonctions de hachage ([SWS_CRYPT_20747]) ou des instances de signataire et de vérificateur ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) via leur fournisseur (AUTOSAR AP EXP SWArchitecture p. 99). Le traitement suit un cycle de vie déterministe : après la liaison de la clé (SetKey), la transformation est initiée via Start(), transmise en flux via Update() et finalisée avec Finish() (AUTOSAR AP TR SystemTests p. 206, EXP SWArchitecture p. 104). Des AllowedUsageFlags immuables empêchent efficacement toute utilisation non autorisée de la clé ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests p. 177).

Diagramme d'états : cycle de vie des contextes de transformation cryptographique, de l'allocation à la réinitialisation. Sources : [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Les certificats et les CSR sont gérés via le X509Provider ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), tandis que les contextes de validation vérifient les chaînes de certificats en prenant en compte les listes de révocation CRL ([SWS_CRYPT_50183]) et les réponses OCSP ([SWS_CRYPT_50124]) (AUTOSAR AP TR SystemTests p. 194). L'attribution des KeySlots et des certificats aux applications s'effectue sur la base de modèles dans le manifeste via InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification p. 245, AUTOSAR AP TPS ManifestSpecification p. 649). L'ensemble des interfaces opère sans exceptions avec des retours ara::core::Result et signale les erreurs via le CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography p. 208).

plus ›

Architecture, domaines de sécurité et isolation par démon

Le cluster fonctionnel Cryptography (ara::crypto) forme la base de sécurité centrale de l'AUTOSAR Adaptive Platform et fournit des mécanismes cryptographiques de base, la gestion des clés ainsi que des services de certificats (PlatformDesign p. 71). Conformément au modèle de confiance de la plateforme, les clusters fonctionnels de plateforme font partie du socle de confiance, tandis que les Adaptive Applications sont exécutées dans l'espace utilisateur non privilégié (SWS Cryptography p. 37). Afin de protéger efficacement le matériel de clé et les opérations cryptographiques, même en cas de compromission potentielle d'une application, l'architecture est généralement conçue autour d'un démon ; l'exécution proprement dite et la conservation des clés demeurent dans un processus de plateforme isolé ou dans un environnement d'exécution sécurisé (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87).

L'architecture divise la fonctionnalité cryptographique en trois domaines principaux : le CryptoProvider pour les primitives de calcul et les transformations de clés, l'espace de stockage de clés (ara::crypto::keys) pour la conservation persistante des objets, ainsi que le X509Provider (ara::crypto::x509) pour la gestion des certificats (SWS Cryptography p. 39, SWS Cryptography p. 87). Plusieurs instances spécialisées de CryptoProvider peuvent coexister en parallèle sur un calculateur, par exemple pour interfacer différents modules matériels de sécurité (HSM, TPM) ou des pilotes logiciels (SWS Cryptography p. 39). Il n'existe toutefois délibérément aucune interopérabilité entre les différents fournisseurs : un objet cryptographique ou une clé appartient exactement à un seul fournisseur et ne peut pas être traité par un autre fournisseur (SWS Cryptography p. 39). Cette encapsulation stricte est vraisemblablement due au fait que les domaines de sécurité matériels imposent physiquement les limites de leurs clés et que les descripteurs de clés ne sont pas valides d'un domaine à l'autre. Question Q-63efe107cf111983 (ouverte)

Diagramme de contexte : relations d'architecture et de composants du cluster fonctionnel Cryptography entre application, démon et fournisseurs. Sources : SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Points d'entrée et initialisation des fournisseurs cryptographiques

L'entrée dans le module s'effectue par des fonctions d'entrée globales qui servent de fabriques pour les interfaces d'abstraction centrales (SWArchitecture p. 71). Les applications créent ou chargent une instance d'un CryptoProvider via la fonction [SWS_CRYPT_20099] en indiquant un ara::core::InstanceSpecifier modélisé. Pour la gestion des certificats, il n'existe dans l'ensemble du système qu'un seul fournisseur de certificats global, qui est chargé via [SWS_CRYPT_40099] (SWS Cryptography p. 39). Des services auxiliaires globaux sont également disponibles, notamment la génération directe de données aléatoires via [SWS_CRYPT_30098] ainsi que l'interrogation d'un compteur de sécurité matériel via [SWS_CRYPT_20098] (SWArchitecture p. 71).

Les ressources de clés persistantes ne sont pas instanciées directement, mais chargées via des emplacements logiques de clés (KeySlots). À cette fin, l'environnement d'exécution fournit les fonctions [SWS_CRYPT_50004] pour les accès en lecture seule et [SWS_CRYPT_50005] pour les emplacements de clés accessibles en écriture, qui valident l'identifiant d'instance transmis par rapport à la configuration des autorisations (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649). Via une instance de KeySlot obtenue, l'instance de fournisseur associée peut être interrogée au moyen de [SWS_CRYPT_30403], ce qui garantit le maintien d'une liaison étroite entre l'emplacement de stockage et l'environnement d'exécution (SWS Cryptography p. 39).

Dès qu'une instance de CryptoProvider est disponible, elle agit comme une fabrique centrale pour l'instanciation de contextes de travail cryptographiques spécifiques (AUTOSAR AP EXP SWArchitecture p. 99). Parmi les contextes pouvant être créés figurent notamment des contextes pour générateurs de nombres aléatoires ([SWS_CRYPT_20741]), chiffrements symétriques par blocs et par flux ([SWS_CRYPT_20742]), chiffrement authentifié ([SWS_CRYPT_20745]), codes d'authentification de message ([SWS_CRYPT_20746]), fonctions de hachage cryptographique ([SWS_CRYPT_20747]), chiffrement ou déchiffrement asymétrique ([SWS_CRYPT_20750], [SWS_CRYPT_20751]) ainsi que des contextes de signature et de vérification ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture p. 99).

Contextes de transformation cryptographique et traitement des données

Le traitement des données cryptographiques dans ara::crypto suit un cycle de vie strictement basé sur des états, garantissant le découplage entre la configuration de l'algorithme, la liaison de la clé et le traitement en flux (AUTOSAR AP TR SystemTests p. 211). Après l'allocation du contexte via le fournisseur, celui-ci se trouve initialement dans l'état non initialisé. Ce n'est que par la transmission d'une clé compatible via les surcharges typées de SetKey() — par exemple pour les clés symétriques ([SWS_CRYPT_23911]), les clés privées ([SWS_CRYPT_23515]) ou directement depuis un KeySlot ([SWS_CRYPT_50043]) — que le contexte passe à l'état prêt (AUTOSAR AP TR SystemTests p. 206).

Pour les traitements en flux, la transformation est initiée par Start(), éventuellement en transmettant un vecteur d'initialisation ou un contexte ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). Ensuite, les blocs de données peuvent être injectés progressivement via Update() ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). En cas de chiffrement authentifié (AEAD), l'interface sépare strictement les données associées, traitées via [SWS_CRYPT_20313], des données utiles confidentielles via [SWS_CRYPT_50074] (EXP SWArchitecture p. 104). La conclusion d'une transformation s'effectue via Finish() ou FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), après quoi les étiquettes d'authentification ou les sommes de contrôle peuvent être lues via GetDigest() ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

Outre le mode de traitement en flux, les classes de contexte telles que les chiffrements symétriques et les chiffrements authentifiés prennent en charge des appels uniques compacts via [SWS_CRYPT_50047] ou [SWS_CRYPT_50078], ce qui permet de chiffrer ou de déchiffrer efficacement de petites charges utiles sans appel de protocole multi-étapes (SWS Cryptography p. 58). Si une opération en cours doit être interrompue, un appel à Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) ou à Reset() ([SWS_CRYPT_50212]) ramène de manière déterministe le contexte à l'état initial réinitialisé (EXP SWArchitecture p. 100).

Diagramme d'états : cycle de vie des contextes de transformation cryptographique, de l'allocation à la réinitialisation. Sources : [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Gestion des clés, encapsulation et application des autorisations

Dans le modèle objet, les clés cryptographiques sont typées en tant que CryptoObject ou RestrictedUseObject (AUTOSAR AP EXP SWArchitecture p. 111, EXP SWArchitecture p. 111). Le standard de la plateforme distingue les clés symétriques (SymmetricKey), les clés asymétriques privées (PrivateKey) et les clés publiques (PublicKey) (SWS Cryptography p. 291). Le matériel de clé peut être généré directement via le CryptoProvider ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) ou dérivé d'un matériel de clé existant en paramétrant un KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) avec une clé de base et en l'exécutant via [SWS_CRYPT_21515] (EXP SWArchitecture p. 108).

Pour appliquer le principe du moindre privilège, chaque objet clé comporte des restrictions d'utilisation immuables (AllowedUsageFlags), qui peuvent être interrogées via [SWS_CRYPT_50092] (AUTOSAR AP TR SystemTests p. 177). La pile cryptographique valide à chaque tentative de liaison (SetKey) si l'opération du contexte cible (par exemple le chiffrement, la signature, la dérivation ou l'exportation) est autorisée par les indicateurs de la clé, et rejette strictement les utilisations non autorisées (AUTOSAR AP TR SystemTests p. 177, SWArchitecture p. 95). L'affectation par défaut pour un algorithme peut être déterminée via [SWS_CRYPT_20955].

Pour l'échange sécurisé de clés, le module implémente plusieurs procédés standardisés : lors d'un accord de clé asymétrique (Diffie-Hellman / ECDH), un KeyAgreementPrivateCtx est créé via [SWS_CRYPT_20758], auquel la clé privée est liée ([SWS_CRYPT_21313]) ; la méthode [SWS_CRYPT_21312] calcule ensuite la clé cible symétrique commune en intégrant la clé publique de la partie distante (AUTOSAR AP TR SystemTests p. 179). Dans le cas du Key Encapsulation Mechanism (KEM), un KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) encapsule une clé symétrique au moyen de [SWS_CRYPT_21813], tandis que la partie distante effectue la décapsulation via un KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) au moyen de [SWS_CRYPT_21412] (AUTOSAR AP TR SystemTests p. 173, AUTOSAR TR AdaptivePlatformSystemTests p. 188). Le Key Wrapping ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) et l'exportation sécurisée ([SWS_CRYPT_20728]) sont disponibles pour le transport protégé de clés (AUTOSAR AP TR SystemTests p. 174, AUTOSAR AP TR SystemTests p. 182).

Diagramme de séquence : accord de clé asymétrique via Diffie-Hellman et dérivation de clés utiles symétriques. Sources : [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests p. 179.

Les signatures asymétriques sont traitées via des contextes distincts : la signature s'effectue via un SignerPrivateCtx ([SWS_CRYPT_20756]) et la méthode [SWS_CRYPT_23512], tandis que la vérification est réalisée via un VerifierPublicCtx ([SWS_CRYPT_20757]) et la méthode [SWS_CRYPT_24112] (AUTOSAR AP TR SystemTests p. 164, SWArchitecture p. 84). Si un KeySlot est mis à jour en arrière-plan par des services de gestion privilégiés (par ex. un renouvellement de clé OTA), les bibliothèques consommatrices peuvent être notifiées via un observateur de mise à jour au moyen de [SWS_CRYPT_30404] afin de recharger de manière synchrone leur matériel de clé (AUTOSAR AP SWS Cryptography p. 36).

Diagramme de séquence : déroulement de la génération et de la vérification de signature à l'aide de contextes privés et publics distincts. Sources : [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests p. 164.

Gestion, validation et groupes de certificats X.509

Le sous-système ara::crypto::x509 fournit des fonctionnalités standardisées pour les infrastructures à clés publiques (PKI) (EXP SWArchitecture p. 116). Le X509Provider central ([SWS_CRYPT_40099]) prend en charge aussi bien la mémoire de session volatile que les stockages persistants (SWS Cryptography p. 39). Les certificats et les chaînes sont analysés à partir de tampons d'octets via [SWS_CRYPT_40614] ou [SWS_CRYPT_40616]. Pour demander de nouveaux certificats d'identité, les applications peuvent générer des demandes de signature de certificat (CSR) signées cryptographiquement via [SWS_CRYPT_40640], le contexte de signataire et le Distinguished Name (DN) étant transmis via [SWS_CRYPT_50186] (AUTOSAR AP TR SystemTests p. 189).

Pour le contrôle de conformité et de validité, l'application instancie un CertificateValidationCtx via [SWS_CRYPT_50125]. Des ancres de confiance (Trust Anchors) sont ajoutées à ce contexte via [SWS_CRYPT_50117], des options de validation sont définies via [SWS_CRYPT_50120] et des horodatages de référence sont enregistrés via [SWS_CRYPT_50121]. La vérification hiérarchique de la chaîne par rapport à la chaîne de confiance s'effectue via [SWS_CRYPT_50122] ou [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests p. 194). Pour la prise en compte des révocations de certificats, des listes de révocation de certificats (CRL) peuvent être importées ([SWS_CRYPT_50183]) ou des requêtes en ligne sur le statut des certificats (OCSP selon la RFC 6960) peuvent être intégrées à l'état de validation via [SWS_CRYPT_40626], [SWS_CRYPT_50185] et [SWS_CRYPT_50124] (AUTOSAR AP TR SystemTests p. 194).

Afin de découpler les consommateurs de certificats des instances de certificats individuelles lors du renouvellement des clés, le manifeste prend en charge le concept de CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification p. 657). Les applications consommatrices chargent l'ensemble du groupe de certificats logiquement liés via [SWS_CRYPT_50126], tandis que des services d'administration privilégiés peuvent remplacer ou purger dynamiquement les certificats via [SWS_CRYPT_50127] et [SWS_CRYPT_50128] (AUTOSAR AP TPS ManifestSpecification p. 657).

Diagramme de séquence : validation de certificat X.509 avec chaîne de certificats, import de CRL et vérification de statut OCSP en ligne. Sources : [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests p. 194.

Modélisation du manifeste, interfaces de port et déploiement

L'intégration des ressources cryptographiques dans une architecture globale de véhicule s'effectue de manière déclarative via le métamodèle AUTOSAR dans le manifeste ARXML (AUTOSAR AP TPS ManifestSpecification p. 244). Les composants logiciels modélisent leurs exigences de sécurité au niveau de la conception via des ports (RPortPrototype), qui sont typés par des spécialisations de CryptoInterface : CryptoKeySlotInterface pour les emplacements de clés, CryptoCertificateInterface pour les ressources de certificats et CryptoProviderInterface pour l'accès aux fournisseurs d'exécution (TPS ManifestSpecification p. 167, AUTOSAR AP TPS ManifestSpecification p. 245). Les attributs des interfaces définissent de manière immuable si des droits de lecture ou d'écriture sont accordés (writeAccess) et quels types d'objets sont autorisés (TPS ManifestSpecification p. 168, TPS ManifestSpecification p. 438).

Dans le manifeste de déploiement, la configuration cible (Target Configuration) relie les prototypes de ports abstraits aux ressources de plateforme physiques concrètes (AUTOSAR AP TPS ManifestSpecification p. 649). L'élément de métamodèle CryptoKeySlotToPortPrototypeMapping mappe le port d'un processus sur un CryptoKeySlot déclaré dans le CryptoModuleInstantiation de la machine (TPS ManifestSpecification p. 614, TPS ManifestSpecification p. 646). De manière analogue, CryptoCertificateToPortPrototypeMapping associe des certificats (TPS ManifestSpecification p. 655). Au moment de l'exécution, le chemin du port dans le manifeste représente le ara::core::InstanceSpecifier, que le code applicatif transmet aux fonctions de chargement telles que [SWS_CRYPT_50004] (ManifestSpecification p. 154).

Pour les interactions de plateforme entre clusters fonctionnels – par exemple entre le Communication Management (SecOC, IPsec, TLS) et la pile cryptographique –, il n'existe pas de prototypes de port classiques (TPS ManifestSpecification p. 861). Ici, le InstanceSpecifier est formé à la place par des éléments dérivés de FunctionalClusterInteractsWithFunctionalClusterMapping, par exemple ComKeyToCryptoKeySlotMapping ou SecOcJobMapping (TPS ManifestSpecification p. 861, TPS ManifestSpecification p. 864, ManifestSpecification p. 411). La sécurisation de la persistance (Persistency Deployment) et les sommes de contrôle des clusters logiciels intègrent également leurs clés et leurs fournisseurs via ces mappages de manifeste standardisés (TPS ManifestSpecification p. 867, TPS ManifestSpecification p. 896).

Comportement en cas d'erreur

Le concept de gestion des erreurs du module cryptographique suit les exigences strictes de l'Adaptive Platform relatives au code insensible aux erreurs et sans exception (noexcept) (SWS Cryptography p. 145). Toutes les opérations synchrones renvoient les situations d'erreur via le type de résultat générique ara::core::Result<T, ara::core::ErrorCode> (SWS Cryptography p. 208). Les codes d'erreur sont ancrés dans un domaine d'erreur dédié, représenté via [SWS_CRYPT_19902] ; son nom peut être interrogé via [SWS_CRYPT_19950] et la description textuelle de l'erreur via [SWS_CRYPT_19953]. Pour les applications qui utilisent explicitement la gestion des exceptions, la pile fournit le type d'exception CryptoException ([SWS_CRYPT_19906]) et la fonction utilitaire [SWS_CRYPT_19954].

Les codes d'erreur fonctionnels typiques comprennent des violations de contexte telles que CryptoErrc::kUninitializedContext, lorsque des opérations cryptographiques sont déclenchées avant l'appel de SetKey(), ou CryptoErrc::kInvalidInputSize, lorsque les tampons de données d'entrée transmis ne correspondent pas à la grille de blocs requise (SWS Cryptography p. 208). Lors des opérations de sérialisation et de conversion, CryptoErrc::kUnknownIdentifier signale des valeurs d'argument non prises en charge et CryptoErrc::kIncompatibleArguments des combinaisons de paramètres incompatibles (SWS Cryptography p. 145). Lors de l'accès aux ressources de clés, la pile empêche les accès non autorisés en renvoyant kAccessViolation (SWS Cryptography p. 87). Lors de l'analyse d'extensions de certificat X.509 personnalisées défectueuses, l'analyseur s'interrompt avec CryptoErrc::kRuntimeFault (SWS Cryptography p. 280, SWS Cryptography p. 356).

Afin de rétablir un état défini dans le contexte après la survenance d'une erreur et d'éviter les fuites de mémoire ou les tampons de streaming bloqués dans le démon, l'appelant doit nettoyer le contexte. Cela s'effectue soit de manière ciblée par l'appel de Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), ce qui élimine les transformations inachevées, soit par Reset() ([SWS_CRYPT_50212]), ce qui réinitialise entièrement le contexte dans l'état antérieur à la liaison de la clé (EXP SWArchitecture p. 100).

Preuves détaillées supplémentaires

La spécification du module Cryptography s'appuie sur une série d'exigences et de documents d'architecture centraux, présentés ci-après :

• Points d'entrée globaux et fabriques : les spécifications [SWS_CRYPT_20099] (LoadCryptoProvider) et [SWS_CRYPT_40099] (LoadX509Provider) définissent l'accès normatif aux deux domaines de fournisseurs primaires (SWArchitecture p. 71, SWS Cryptography p. 39).
• Conservation des clés et liaison de port : les fonctions [SWS_CRYPT_50004] (LoadKeySlot) et [SWS_CRYPT_50005] (LoadWriteableKeySlot) mettent en œuvre de manière contraignante l'interaction entre la modélisation des ports dans le manifeste et l'accès isolé à la mémoire physique dans le KSP (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649).
• Fabriques de primitives et de contextes : le groupe d'interfaces constitué de [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx) et [SWS_CRYPT_20757] (CreateVerifierPublicCtx) définit la génération dynamique de machines d'état standardisées pour les tâches cryptographiques (AUTOSAR AP EXP SWArchitecture p. 99, AUTOSAR AP TR SystemTests p. 164).
• Validation X.509 et contrôle de révocation : avec [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl) et [SWS_CRYPT_50124] (AddOcspResponse), une chaîne complète de contrôle PKI adaptée à l'automobile est normalisée (AUTOSAR AP TR SystemTests p. 194, EXP SWArchitecture p. 116).