module ara::crypto — Cryptography

Het functionele cluster Cryptography biedt gestandaardiseerde beveiligingsdiensten voor symmetrische en asymmetrische encryptie, verificatie van handtekeningen en veilig sleutel- en certificaatbeheer (PlatformDesign p. 71). De toegang tot cryptografische operaties en persistente sleutelposities vindt strikt geïsoleerd plaats via platformspecifieke providers en declaratief in het manifest verankerde instantiespecificaties (SWS Cryptography p. 39). De handhaving van gebruiksbeperkingen voorkomt daarbij compromittering van het gevoelige sleutelmateriaal ([SWS_CRYPT_50092]).

meer ›

Het functionele cluster Cryptography (ara::crypto) biedt een omvattende beveiligingsarchitectuur voor het AUTOSAR Adaptive Platform (PlatformDesign p. 71). Ter beveiliging tegen gecompromitteerde gebruikerstoepassingen zijn sleutelopslag en cryptografische uitvoering doorgaans ingekapseld in een geïsoleerde platformdaemon of Hardware Security Module (HSM) (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87). De totale functionaliteit is onderverdeeld in gespecialiseerde CryptoProvider voor computationele primitieven, het Key-Storage-gedeelte voor persistente sleutelposities (KeySlots) en een machinewijde X509Provider voor het PKI-certificaatbeheer (SWS Cryptography p. 39).

Contextdiagram: architectuur- en componentrelaties van het Functional Cluster Cryptography tussen applicatie, daemon en providers. Bronnen: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Applicaties maken cryptografische contexten zoals symmetrische cijfers ([SWS_CRYPT_20742]), geauthenticeerde cijfers ([SWS_CRYPT_20745]), hashfuncties ([SWS_CRYPT_20747]) of signer- en verifier-instanties ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) aan via hun provider (AUTOSAR AP EXP SWArchitecture p. 99). De verwerking volgt een deterministische levenscyclus: na sleutelbinding (SetKey) wordt de transformatie via Start() gestart, via Update() gestreamd en met Finish() afgesloten (AUTOSAR AP TR SystemTests p. 206, EXP SWArchitecture p. 104). Onveranderlijke AllowedUsageFlags voorkomen doeltreffend ongeautoriseerd sleutelgebruik ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests p. 177).

Toestandsdiagram: levenscyclus van cryptografische transformatiecontexten van toewijzing tot reset. Bronnen: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Certificaten en CSR's worden beheerd via de X509Provider ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), terwijl validatiecontexten certificaatketens controleren rekening houdend met CRL-intrekkingslijsten ([SWS_CRYPT_50183]) en OCSP-antwoorden ([SWS_CRYPT_50124]) (AUTOSAR AP TR SystemTests p. 194). De toewijzing van KeySlots en certificaten aan applicaties gebeurt modelgebaseerd in het manifest via InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification p. 245, AUTOSAR AP TPS ManifestSpecification p. 649). Alle interfaces werken met uitzonderingsloze ara::core::Result-retourwaarden en signaleren fouten via de CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography p. 208).

meer ›

Architectuur, beveiligingsdomeinen en daemonisolatie

Het functionele cluster Cryptography (ara::crypto) vormt de centrale beveiligingsbasis van het AUTOSAR Adaptive Platform en biedt cryptografische basismechanismen, sleutelbeheer en certificaatdiensten (PlatformDesign p. 71). Conform het vertrouwensmodel van het platform behoren functionele platformclusters tot het betrouwbare fundament, terwijl Adaptive Applications in de niet-geprivilegieerde gebruikersruimte worden uitgevoerd (SWS Cryptography p. 37). Om sleutelmateriaal en cryptografische operaties ook bij een potentiële compromittering van een applicatie doeltreffend te beveiligen, is de architectuur doorgaans daemon-gebaseerd ontworpen; de daadwerkelijke uitvoering en sleutelopslag blijven in een geïsoleerd platformproces of in een veilige uitvoeringsomgeving (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87).

De architectuur verdeelt de cryptografische functionaliteit in drie primaire domeinen: de CryptoProvider voor computationele primitieven en sleuteltransformaties, het Key-Storage-gedeelte (ara::crypto::keys) voor het persistent bewaren van objecten en de X509Provider (ara::crypto::x509) voor het certificaatbeheer (SWS Cryptography p. 39, SWS Cryptography p. 87). Op een ECU kunnen meerdere gespecialiseerde instanties van CryptoProvider parallel bestaan, bijvoorbeeld voor het aansluiten van verschillende Hardware Security Modules (HSM, TPM) of softwaregebaseerde drivers (SWS Cryptography p. 39). Tussen verschillende providers bestaat echter bewust geen interoperabiliteit: een cryptografisch object of een sleutel behoort exact tot één provider en kan niet door een andere provider worden verwerkt (SWS Cryptography p. 39). Deze strikte inkapseling is vermoedelijk primair toe te schrijven aan het feit dat hardware-beveiligingsdomeinen hun sleutelgrenzen fysiek afdwingen en key handles niet domeinoverschrijdend geldig zijn. Vraag Q-63efe107cf111983 (open)

Contextdiagram: architectuur- en componentrelaties van het Functional Cluster Cryptography tussen applicatie, daemon en providers. Bronnen: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Toegangspunten en initialisatie van de cryptografische providers

De toegang tot de module verloopt via globale instapfuncties die dienen als factories voor de centrale abstractie-interfaces (SWArchitecture p. 71). Applicaties creëren of laden een instantie van een CryptoProvider via de functie [SWS_CRYPT_20099] onder vermelding van een gemodelleerde ara::core::InstanceSpecifier. Voor het certificaatbeheer bestaat in het totale systeem exact één globale certificaatprovider die via [SWS_CRYPT_40099] wordt geladen (SWS Cryptography p. 39). Aanvullend zijn er globale hulpdiensten beschikbaar, waaronder het direct genereren van willekeurige gegevens via [SWS_CRYPT_30098] en het opvragen van een hardwareondersteunde beveiligingsteller via [SWS_CRYPT_20098] (SWArchitecture p. 71).

Persistente sleutelbronnen worden niet direct geïnstantieerd, maar geladen via logische sleutelposities (KeySlots). Hiertoe stelt de runtime-omgeving de functies [SWS_CRYPT_50004] voor alleen-lezen-toegang en [SWS_CRYPT_50005] voor beschrijfbare sleutelposities beschikbaar, die de meegegeven instantie-identifier valideren tegen de autorisatieconfiguratie (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649). Via een verkregen KeySlot-instantie kan de toegewezen provider-instantie worden opgevraagd door middel van [SWS_CRYPT_30403], waardoor de hechte binding tussen opslaglocatie en uitvoeringsomgeving gewaarborgd blijft (SWS Cryptography p. 39).

Zodra een CryptoProvider-instantie beschikbaar is, fungeert deze als centrale factory voor het instantiëren van specifieke cryptografische werkcontexten (AUTOSAR AP EXP SWArchitecture p. 99). Tot de te creëren contexten behoren onder meer contexten voor random number generators ([SWS_CRYPT_20741]), symmetrische blok- en stroomcijfers ([SWS_CRYPT_20742]), geauthenticeerde encryptie ([SWS_CRYPT_20745]), Message Authentication Codes ([SWS_CRYPT_20746]), cryptografische hashfuncties ([SWS_CRYPT_20747]), asymmetrische encryptie resp. decryptie ([SWS_CRYPT_20750], [SWS_CRYPT_20751]) evenals signatuur- en verificatiecontexten ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture p. 99).

Cryptografische transformatiecontexten en gegevensverwerking

De verwerking van cryptografische gegevens in ara::crypto volgt een strikt toestandsgebaseerde levenscyclus, die de ontkoppeling van algoritmeconfiguratie, sleutelbinding en streamingverwerking waarborgt (AUTOSAR AP TR SystemTests p. 211). Na de toewijzing van de context via de provider bevindt deze zich eerst in de niet-geïnitialiseerde toestand. Pas door de overdracht van een compatibele sleutel via de typespecifieke overloads van SetKey() – bijvoorbeeld voor symmetrische sleutels ([SWS_CRYPT_23911]), privésleutels ([SWS_CRYPT_23515]) of direct vanuit een KeySlot ([SWS_CRYPT_50043]) – gaat de context over naar de gereedtoestand (AUTOSAR AP TR SystemTests p. 206).

Voor streamingverwerkingen wordt de transformatie geïnitieerd door Start(), optioneel onder doorgifte van een initialisatievector of context ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). Vervolgens kunnen gegevensblokken stapsgewijs via Update() worden ingevoerd ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). Bij geauthenticeerde encryptie (AEAD) scheidt de interface strikt tussen geassocieerde gegevens, die via [SWS_CRYPT_20313] worden verwerkt, en vertrouwelijke payload via [SWS_CRYPT_50074] (EXP SWArchitecture p. 104). De voltooiing van een transformatie vindt plaats via Finish() resp. FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), waarna authenticatietags of checksums via GetDigest() kunnen worden uitgelezen ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

Naast de streamingmodus ondersteunen contextklassen zoals symmetrische cijfers en geauthenticeerde cijfers compacte eenmalige aanroepen via [SWS_CRYPT_50047] of [SWS_CRYPT_50078], waardoor korte payloads efficiënt zonder meerstaps protocoloproep kunnen worden ver- of ontsleuteld (SWS Cryptography p. 58). Mocht een lopende operatie moeten worden afgebroken, brengt een aanroep van Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) of Reset() ([SWS_CRYPT_50212]) de context deterministisch terug naar de geschoonde begintoestand (EXP SWArchitecture p. 100).

Toestandsdiagram: levenscyclus van cryptografische transformatiecontexten van toewijzing tot reset. Bronnen: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Sleutelbeheer, inkapseling en handhaving van autorisaties

Cryptografische sleutels worden in het objectmodel getypeerd als CryptoObject resp. RestrictedUseObject (AUTOSAR AP EXP SWArchitecture p. 111, EXP SWArchitecture p. 111). De platformstandaard onderscheidt symmetrische sleutels (SymmetricKey), asymmetrische privésleutels (PrivateKey) en publieke sleutels (PublicKey) (SWS Cryptography p. 291). Sleutelmateriaal kan direct via de CryptoProvider worden gegenereerd ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) of worden afgeleid uit bestaand sleutelmateriaal door een KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) te parametreren met een basissleutel en uit te voeren via [SWS_CRYPT_21515] (EXP SWArchitecture p. 108).

Voor de handhaving van het principe van minimale rechten bevat elk sleutelobject onveranderlijke gebruiksbeperkingen (AllowedUsageFlags), die via [SWS_CRYPT_50092] kunnen worden opgevraagd (AUTOSAR AP TR SystemTests p. 177). De crypto-stack valideert bij elke bindingspoging (SetKey) of de operatie van de doelcontext (bijv. versleutelen, ondertekenen, afleiden of exporteren) geautoriseerd is door de vlaggen van de sleutel, en wijst ontoelaatbaar gebruik strikt af (AUTOSAR AP TR SystemTests p. 177, SWArchitecture p. 95). De standaardinstelling voor een algoritme kan worden bepaald via [SWS_CRYPT_20955].

Voor veilige sleuteluitwisseling implementeert de module meerdere gestandaardiseerde procedures: bij asymmetrische sleutelovereenkomst (Diffie-Hellman / ECDH) wordt via [SWS_CRYPT_20758] een KeyAgreementPrivateCtx aangemaakt waaraan de privésleutel wordt gebonden ([SWS_CRYPT_21313]); de methode [SWS_CRYPT_21312] berekent vervolgens, met inbegrip van de publieke sleutel van de tegenpartij, de gemeenschappelijke symmetrische doelsleutel (AUTOSAR AP TR SystemTests p. 179). Bij het Key Encapsulation Mechanism (KEM) kapselt een KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) een symmetrische sleutel in door middel van [SWS_CRYPT_21813], terwijl de tegenpartij de decapsulatie uitvoert via een KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) via [SWS_CRYPT_21412] (AUTOSAR AP TR SystemTests p. 173, AUTOSAR TR AdaptivePlatformSystemTests p. 188). Voor beveiligd sleuteltransport staan Key Wrapping ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) en beveiligde export ([SWS_CRYPT_20728]) ter beschikking (AUTOSAR AP TR SystemTests p. 174, AUTOSAR AP TR SystemTests p. 182).

Sequentiediagram: Asymmetrische sleutelovereenkomst via Diffie-Hellman en afleiding van symmetrische werksleutels. Bronnen: [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests p. 179.

Asymmetrische handtekeningen worden via gescheiden contexten afgehandeld: Het ondertekenen vindt plaats via een SignerPrivateCtx ([SWS_CRYPT_20756]) en de methode [SWS_CRYPT_23512], terwijl de verificatie via een VerifierPublicCtx ([SWS_CRYPT_20757]) en de methode [SWS_CRYPT_24112] wordt voltrokken (AUTOSAR AP TR SystemTests p. 164, SWArchitecture p. 84). Wordt een KeySlot op de achtergrond door geprivilegieerde beheerdiensten (bijv. OTA-key-rollover) bijgewerkt, dan kunnen consumerende bibliotheken via een update-observer via [SWS_CRYPT_30404] op de hoogte worden gesteld om hun sleutelmateriaal synchroon na te laden (AUTOSAR AP SWS Cryptography p. 36).

Sequentiediagram: Verloop van het genereren en verifiëren van handtekeningen met gebruikmaking van gescheiden private en publieke contexten. Bronnen: [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests p. 164.

X.509-certificaatbeheer, validatie en groepen

Het subsysteem ara::crypto::x509 stelt gestandaardiseerde functies voor Public Key Infrastructures (PKI) beschikbaar (EXP SWArchitecture p. 116). De centrale X509Provider ([SWS_CRYPT_40099]) ondersteunt zowel vluchtig sessiegeheugen als persistente opslaglocaties (SWS Cryptography p. 39). Certificaten en ketens worden via [SWS_CRYPT_40614] respectievelijk [SWS_CRYPT_40616] uit bytebuffers geparsed. Voor het aanvragen van nieuwe identiteitscertificaten kunnen applicaties via [SWS_CRYPT_40640] cryptografisch ondertekende Certificate Signing Requests (CSR) genereren, waarbij de signer-context en de Distinguished Name (DN) via [SWS_CRYPT_50186] worden overgedragen (AUTOSAR AP TR SystemTests p. 189).

Voor de conformiteits- en geldigheidscontrole instantieert de applicatie via [SWS_CRYPT_50125] een CertificateValidationCtx. Aan deze context worden vertrouwensankers (trust anchors) via [SWS_CRYPT_50117] toegevoegd, validatieopties via [SWS_CRYPT_50120] gedefinieerd en referentietijdstempels via [SWS_CRYPT_50121] vastgelegd. De hiërarchische ketencontrole ten opzichte van de vertrouwensketen vindt plaats via [SWS_CRYPT_50122] respectievelijk [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests p. 194). Voor het registreren van certificaatintrekkingen kunnen Certificate Revocation Lists (CRL) worden geïmporteerd ([SWS_CRYPT_50183]) of online controles van de certificaatstatus (OCSP conform RFC 6960) via [SWS_CRYPT_40626], [SWS_CRYPT_50185] en [SWS_CRYPT_50124] in de validatiestatus worden opgenomen (AUTOSAR AP TR SystemTests p. 194).

Om certificaatconsumenten bij sleutelwisselingen te ontkoppelen van individuele certificaatinstanties, ondersteunt het manifest het concept van de CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification p. 657). Consumerende applicaties laden via [SWS_CRYPT_50126] de volledige groep van logisch gekoppelde certificaten, terwijl geprivilegieerde administratiediensten certificaten via [SWS_CRYPT_50127] en [SWS_CRYPT_50128] dynamisch kunnen vervangen of opschonen (AUTOSAR AP TPS ManifestSpecification p. 657).

Sequentiediagram: X.509-certificaatvalidatie met certificaatketen, CRL-import en online OCSP-statuscontrole. Bronnen: [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests p. 194.

Manifest-modellering, port-interfaces en deployment

De integratie van cryptografische resources in een algehele voertuigarchitectuur vindt declaratief plaats via het AUTOSAR-metamodel in het ARXML-manifest (AUTOSAR AP TPS ManifestSpecification p. 244). Softwarecomponenten modelleren hun beveiligingseisen op ontwerpniveau via poorten (RPortPrototype), die door specialisaties van CryptoInterface worden getypeerd: CryptoKeySlotInterface voor sleutelposities, CryptoCertificateInterface voor certificaatresources en CryptoProviderInterface voor de toegang tot uitvoeringsproviders (TPS ManifestSpecification p. 167, AUTOSAR AP TPS ManifestSpecification p. 245). De attributen van de interfaces leggen onveranderlijk vast of lees- of schrijfrechten worden verleend (writeAccess) en welke objecttypen zijn toegestaan (TPS ManifestSpecification p. 168, TPS ManifestSpecification p. 438).

In het deployment-manifest verbindt de doelconfiguratie (Target Configuration) de abstracte poortprototypes met concrete fysieke platformresources (AUTOSAR AP TPS ManifestSpecification p. 649). Het metamodelelement CryptoKeySlotToPortPrototypeMapping mapt de poort van een proces op een in de CryptoModuleInstantiation van de machine gedeclareerde CryptoKeySlot (TPS ManifestSpecification p. 614, TPS ManifestSpecification p. 646). Op analoge wijze wijst CryptoCertificateToPortPrototypeMapping certificaten toe (TPS ManifestSpecification p. 655). Tijdens runtime representeert het pad van de poort in het manifest het ara::core::InstanceSpecifier, dat de applicatiecode aan laadfuncties zoals [SWS_CRYPT_50004] overdraagt (ManifestSpecification p. 154).

Voor platforminteracties tussen functionele clusters – bijvoorbeeld tussen Communication Management (SecOC, IPsec, TLS) en de cryptostack – bestaan geen klassieke poortprototypes (TPS ManifestSpecification p. 861). Hier wordt het InstanceSpecifier in plaats daarvan gevormd door elementen die zijn afgeleid van FunctionalClusterInteractsWithFunctionalClusterMapping, bijvoorbeeld ComKeyToCryptoKeySlotMapping of SecOcJobMapping (TPS ManifestSpecification p. 861, TPS ManifestSpecification p. 864, ManifestSpecification p. 411). Ook de beveiliging van persistentie (Persistency Deployment) en controlesommen van softwareclusters integreren hun sleutels en providers via deze gestandaardiseerde manifest-mappings (TPS ManifestSpecification p. 867, TPS ManifestSpecification p. 896).

Gedrag in het foutgeval

Het foutafhandelingsconcept van de cryptomodule volgt de strikte voorschriften van het Adaptive Platform voor foutbestendige en uitzonderingsloze code (noexcept) (SWS Cryptography p. 145). Alle synchrone bewerkingen retourneren foutsituaties via het generieke resultaattype ara::core::Result<T, ara::core::ErrorCode> (SWS Cryptography p. 208). De foutcodes zijn verankerd in een eigen foutdomein, dat via [SWS_CRYPT_19902] wordt gerepresenteerd; de naam ervan kan via [SWS_CRYPT_19950] en de tekstuele foutbeschrijving via [SWS_CRYPT_19953] worden opgevraagd. Voor applicaties die expliciet gebruikmaken van uitzonderingsafhandeling, stelt de stack het uitzonderingstype CryptoException ([SWS_CRYPT_19906]) en de hulpfunctie [SWS_CRYPT_19954] beschikbaar.

Typische functionele foutcodes omvatten contextschendingen zoals CryptoErrc::kUninitializedContext, wanneer cryptografische bewerkingen vóór de aanroep van SetKey() in gang worden gezet, of CryptoErrc::kInvalidInputSize, wanneer de overgedragen invoerdatabuffers niet aansluiten op het vereiste blokraster (SWS Cryptography p. 208). Bij serialisatie- en conversieprocessen signaleert CryptoErrc::kUnknownIdentifier niet-ondersteunde argumentwaarden en CryptoErrc::kIncompatibleArguments incompatibele parametercombinaties (SWS Cryptography p. 145). Bij toegang tot sleutelresources voorkomt de stack ongeautoriseerde toegang door het retourneren van kAccessViolation (SWS Cryptography p. 87). Bij het parsen van foutieve gebruikersgedefinieerde X.509-certificaatextensies breekt de parser af met CryptoErrc::kRuntimeFault (SWS Cryptography p. 280, SWS Cryptography p. 356).

Om na een opgetreden fout een gedefinieerde toestand in de context te herstellen en geheugenlekken of hangende streamingbuffers in de daemon te voorkomen, moet de aanroeper de context opschonen. Dit gebeurt hetzij gericht door het aanroepen van Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), waardoor onvoltooide transformaties worden verworpen, hetzij door Reset() ([SWS_CRYPT_50212]), wat de context volledig terugzet naar de toestand van vóór de sleutelbinding (EXP SWArchitecture p. 100).

Verdere gedetailleerde bewijzen

De specificatie van de module Cryptography steunt op een reeks centrale eisen en architectuurdocumenten, die hierna worden ingedeeld:

• Globale instappunten en factories: De specificaties [SWS_CRYPT_20099] (LoadCryptoProvider) en [SWS_CRYPT_40099] (LoadX509Provider) definiëren de normatieve toegang tot de twee primaire providerdomeinen (SWArchitecture p. 71, SWS Cryptography p. 39).
• Sleutelbeheer en poortbinding: De functies [SWS_CRYPT_50004] (LoadKeySlot) en [SWS_CRYPT_50005] (LoadWriteableKeySlot) implementeren op bindende wijze de wisselwerking tussen poortmodellering in het manifest en geïsoleerde fysieke geheugentoegang in de KSP (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649).
• Primitieven- en contextfactories: De interfacegroep rond [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx) en [SWS_CRYPT_20757] (CreateVerifierPublicCtx) legt de dynamische creatie van gestandaardiseerde toestandsmachines voor cryptotaken vast (AUTOSAR AP EXP SWArchitecture p. 99, AUTOSAR AP TR SystemTests p. 164).
• X.509-validatie en intrekkingscontrole: Met [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl) en [SWS_CRYPT_50124] (AddOcspResponse) wordt een volledige, voor de automobielsector geschikte PKI-controleketen genormeerd (AUTOSAR AP TR SystemTests p. 194, EXP SWArchitecture p. 116).