módulo ara::crypto — Cryptography

O cluster funcional Cryptography fornece serviços padronizados de segurança para criptografia simétrica e assimétrica, verificação de assinaturas, bem como gerenciamento seguro de chaves e certificados (PlatformDesign p. 71). O acesso a operações criptográficas e posições persistentes de chaves ocorre de forma estritamente isolada por meio de provedores específicos da plataforma e especificadores de instância ancorados declarativamente no manifesto (SWS Cryptography p. 39). A aplicação de restrições de uso impede, assim, o comprometimento do material sensível de chave ([SWS_CRYPT_50092]).

mais ›

O cluster funcional Cryptography (ara::crypto) fornece uma arquitetura de segurança abrangente para a AUTOSAR Adaptive Platform (PlatformDesign p. 71). Para a proteção contra aplicações de usuário comprometidas, o armazenamento de chaves e a execução criptográfica são tipicamente encapsulados em um daemon isolado da plataforma ou em um módulo de segurança em hardware (HSM) (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87). A funcionalidade geral divide-se em CryptoProvider especializadas para primitivas de cálculo, a área de armazenamento de chaves para posições persistentes de chave (KeySlots) e um X509Provider em nível de máquina para o gerenciamento de certificados PKI (SWS Cryptography p. 39).

Diagrama de contexto: relações de arquitetura e componentes do Functional Cluster Cryptography entre aplicação, daemon e provedores. Fontes: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

As aplicações criam contextos criptográficos, como cifras simétricas ([SWS_CRYPT_20742]), cifras autenticadas ([SWS_CRYPT_20745]), funções de hash ([SWS_CRYPT_20747]) ou instâncias de Signer e Verifier ([SWS_CRYPT_20756], [SWS_CRYPT_20757]), por meio de seu provedor (AUTOSAR AP EXP SWArchitecture p. 99). O processamento segue um ciclo de vida determinístico: após a vinculação da chave (SetKey), a transformação é iniciada via Start(), transmitida em fluxo via Update() e finalizada com Finish() (AUTOSAR AP TR SystemTests p. 206, EXP SWArchitecture p. 104). AllowedUsageFlags imutáveis impedem eficazmente o uso não autorizado de chaves ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests p. 177).

Diagrama de estados: ciclo de vida de contextos de transformação criptográfica, desde a alocação até o reset. Fontes: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Certificados e CSRs são gerenciados via X509Provider ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), enquanto contextos de validação verificam cadeias de certificados considerando listas de revogação CRL ([SWS_CRYPT_50183]) e respostas OCSP ([SWS_CRYPT_50124]) (AUTOSAR AP TR SystemTests p. 194). A atribuição de KeySlots e certificados a aplicações ocorre de forma baseada em modelo no manifesto via InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification p. 245, AUTOSAR AP TPS ManifestSpecification p. 649). Todas as interfaces operam com retornos ara::core::Result sem exceções e sinalizam erros por meio de CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography p. 208).

mais ›

Arquitetura, domínios de segurança e isolamento de daemon

O cluster funcional Cryptography (ara::crypto) forma a base central de segurança da AUTOSAR Adaptive Platform e fornece mecanismos criptográficos básicos, gerenciamento de chaves e serviços de certificados (PlatformDesign p. 71). De acordo com o modelo de confiança da plataforma, os clusters funcionais da plataforma pertencem à base confiável, enquanto as Adaptive Applications são executadas no espaço de usuário não privilegiado (SWS Cryptography p. 37). Para proteger eficazmente o material de chave e as operações criptográficas mesmo em caso de um potencial comprometimento de uma aplicação, a arquitetura é tipicamente projetada com base em daemon; a execução propriamente dita e o armazenamento de chaves permanecem em um processo isolado da plataforma ou em um ambiente de execução seguro (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87).

A arquitetura divide a funcionalidade criptográfica em três domínios primários: o CryptoProvider para primitivas de cálculo e transformações de chaves, a área de armazenamento de chaves (ara::crypto::keys) para a retenção persistente de objetos e o X509Provider (ara::crypto::x509) para o gerenciamento de certificados (SWS Cryptography p. 39, SWS Cryptography p. 87). Em uma unidade de controle eletrônico, podem coexistir em paralelo várias instâncias especializadas de CryptoProvider, por exemplo, para a conexão de diferentes módulos de segurança em hardware (HSM, TPM) ou drivers baseados em software (SWS Cryptography p. 39). No entanto, não há propositadamente interoperabilidade entre provedores diferentes: um objeto criptográfico ou uma chave pertence exatamente a um provedor e não pode ser processado por outro provedor (SWS Cryptography p. 39). É provável que esse encapsulamento estrito se deva principalmente ao fato de que os domínios de segurança de hardware impõem seus limites de chaves fisicamente e os identificadores de chaves não são válidos entre domínios. Pergunta Q-63efe107cf111983 (aberta)

Diagrama de contexto: relações de arquitetura e componentes do Functional Cluster Cryptography entre aplicação, daemon e provedores. Fontes: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Pontos de entrada e inicialização dos provedores criptográficos

A entrada no módulo ocorre por meio de funções globais de entrada, que servem como fábricas para as interfaces centrais de abstração (SWArchitecture p. 71). As aplicações criam ou carregam uma instância de um CryptoProvider por meio da função [SWS_CRYPT_20099], especificando um ara::core::InstanceSpecifier modelado. Para o gerenciamento de certificados, existe exatamente um provedor de certificados global em todo o sistema, que é carregado via [SWS_CRYPT_40099] (SWS Cryptography p. 39). Adicionalmente, estão disponíveis serviços auxiliares globais, incluindo a geração direta de dados aleatórios via [SWS_CRYPT_30098] e a consulta a um contador de segurança baseado em hardware via [SWS_CRYPT_20098] (SWArchitecture p. 71).

Recursos de chaves persistentes não são instanciados diretamente, mas carregados por meio de posições lógicas de chave (KeySlots). Para isso, o ambiente de execução disponibiliza as funções [SWS_CRYPT_50004] para acessos somente de leitura e [SWS_CRYPT_50005] para posições graváveis de chave, que validam o identificador de instância transmitido em relação à configuração de permissões (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649). Por meio de uma instância de KeySlot obtida, a instância do provedor associado pode ser consultada através de [SWS_CRYPT_30403], garantindo que a forte vinculação entre o local de armazenamento e o ambiente de execução seja mantida (SWS Cryptography p. 39).

Assim que uma instância de CryptoProvider está disponível, ela atua como uma fábrica central para a instanciação de contextos de trabalho criptográficos específicos (AUTOSAR AP EXP SWArchitecture p. 99). Entre os contextos passíveis de criação estão, entre outros, contextos para geradores de números aleatórios ([SWS_CRYPT_20741]), cifras simétricas de bloco e de fluxo ([SWS_CRYPT_20742]), criptografia autenticada ([SWS_CRYPT_20745]), Message Authentication Codes ([SWS_CRYPT_20746]), funções de hash criptográficas ([SWS_CRYPT_20747]), criptografia ou descriptografia assimétrica ([SWS_CRYPT_20750], [SWS_CRYPT_20751]), bem como contextos de assinatura e verificação ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture p. 99).

Contextos de transformação criptográfica e processamento de dados

O processamento de dados criptográficos em ara::crypto segue um ciclo de vida estritamente baseado em estados, o que garante o desacoplamento entre configuração do algoritmo, vinculação da chave e processamento em fluxo (AUTOSAR AP TR SystemTests p. 211). Após a alocação do contexto por meio do provedor, ele se encontra inicialmente no estado não inicializado. Apenas com a passagem de uma chave compatível por meio das sobrecargas específicas de tipo de SetKey() – por exemplo, para chaves simétricas ([SWS_CRYPT_23911]), chaves privadas ([SWS_CRYPT_23515]) ou diretamente de um KeySlot ([SWS_CRYPT_50043]) – o contexto transita para o estado pronto (AUTOSAR AP TR SystemTests p. 206).

Para processamentos em fluxo, a transformação é iniciada por Start(), opcionalmente com a passagem de um vetor de inicialização ou contexto ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). Em seguida, blocos de dados podem ser alimentados passo a passo via Update() ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). Na criptografia autenticada (AEAD), a interface separa estritamente os dados associados, processados via [SWS_CRYPT_20313], dos dados úteis confidenciais via [SWS_CRYPT_50074] (EXP SWArchitecture p. 104). A conclusão de uma transformação ocorre via Finish() ou FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), após o que tags de autenticação ou somas de verificação podem ser lidas via GetDigest() ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

Além do modo de streaming, classes de contexto como cifras simétricas e cifras autenticadas suportam chamadas únicas compactas via [SWS_CRYPT_50047] ou [SWS_CRYPT_50078], permitindo que payloads curtos sejam cifrados ou decifrados com eficiência sem chamadas de protocolo em múltiplas etapas (SWS Cryptography p. 58). Se uma operação em andamento precisar ser cancelada, uma chamada de Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) ou Reset() ([SWS_CRYPT_50212]) retorna o contexto de forma determinística ao estado inicial limpo (EXP SWArchitecture p. 100).

Diagrama de estados: ciclo de vida de contextos de transformação criptográfica, desde a alocação até o reset. Fontes: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Gerenciamento de chaves, encapsulamento e aplicação de permissões

Chaves criptográficas são tipificadas no modelo de objetos como CryptoObject ou RestrictedUseObject (AUTOSAR AP EXP SWArchitecture p. 111, EXP SWArchitecture p. 111). O padrão da plataforma distingue entre chaves simétricas (SymmetricKey), chaves privadas assimétricas (PrivateKey) e chaves públicas (PublicKey) (SWS Cryptography p. 291). O material de chave pode ser gerado diretamente através do CryptoProvider ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) ou derivado a partir de material de chave existente parametrizando um KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) com uma chave base e executando-o via [SWS_CRYPT_21515] (EXP SWArchitecture p. 108).

Para a aplicação do princípio do menor privilégio, cada objeto de chave contém restrições de uso imutáveis (AllowedUsageFlags), que podem ser consultadas via [SWS_CRYPT_50092] (AUTOSAR AP TR SystemTests p. 177). A pilha de criptografia valida a cada tentativa de vinculação (SetKey) se a operação do contexto de destino (por exemplo, criptografar, assinar, derivar ou exportar) está autorizada pelas flags da chave e rejeita estritamente utilizações não permitidas (AUTOSAR AP TR SystemTests p. 177, SWArchitecture p. 95). A atribuição padrão para um algoritmo pode ser determinada via [SWS_CRYPT_20955].

Para a troca segura de chaves, o módulo implementa vários procedimentos padronizados: no acordo de chaves assimétricas (Diffie-Hellman / ECDH), cria-se via [SWS_CRYPT_20758] um KeyAgreementPrivateCtx ao qual a chave privada é vinculada ([SWS_CRYPT_21313]); o método [SWS_CRYPT_21312] calcula em seguida, com a inclusão da chave pública da contraparte, a chave simétrica de destino compartilhada (AUTOSAR AP TR SystemTests p. 179). No Key Encapsulation Mechanism (KEM), um KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) encapsula uma chave simétrica por meio de [SWS_CRYPT_21813], enquanto a contraparte realiza o desencapsulamento por meio de um KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) via [SWS_CRYPT_21412] (AUTOSAR AP TR SystemTests p. 173, AUTOSAR TR AdaptivePlatformSystemTests p. 188). Para o transporte protegido de chaves, estão disponíveis o Key Wrapping ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) e a exportação protegida ([SWS_CRYPT_20728]) (AUTOSAR AP TR SystemTests p. 174, AUTOSAR AP TR SystemTests p. 182).

Diagrama de sequência: acordo de chaves assimétricas via Diffie-Hellman e derivação de chaves úteis simétricas. Fontes: [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests p. 179.

Assinaturas assimétricas são processadas por meio de contextos separados: a assinatura ocorre via um SignerPrivateCtx ([SWS_CRYPT_20756]) e o método [SWS_CRYPT_23512], enquanto a verificação é realizada via um VerifierPublicCtx ([SWS_CRYPT_20757]) e o método [SWS_CRYPT_24112] (AUTOSAR AP TR SystemTests p. 164, SWArchitecture p. 84). Se um KeySlot for atualizado em segundo plano por serviços privilegiados de gerenciamento (por exemplo, OTA-Key-Rollover), bibliotecas consumidoras podem ser notificadas por meio de um observador de atualização via [SWS_CRYPT_30404] para recarregar seu material de chave sincronicamente (AUTOSAR AP SWS Cryptography p. 36).

Diagrama de sequência: fluxo de geração e verificação de assinatura com uso de contextos privados e públicos separados. Fontes: [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests p. 164.

Gerenciamento de certificados X.509, validação e grupos

O subsistema ara::crypto::x509 fornece funções padronizadas para infraestruturas de chaves públicas (PKI) (EXP SWArchitecture p. 116). O X509Provider central ([SWS_CRYPT_40099]) suporta tanto armazenamento volátil de sessão quanto repositórios persistentes (SWS Cryptography p. 39). Certificados e cadeias são analisados a partir de buffers de bytes via [SWS_CRYPT_40614] ou [SWS_CRYPT_40616]. Para a solicitação de novos certificados de identidade, as aplicações podem gerar Certificate Signing Requests (CSR) assinadas criptograficamente via [SWS_CRYPT_40640], sendo o contexto do Signer e o Distinguished Name (DN) passados via [SWS_CRYPT_50186] (AUTOSAR AP TR SystemTests p. 189).

Para a verificação de conformidade e validade, a aplicação instancia um CertificateValidationCtx via [SWS_CRYPT_50125]. A esse contexto são adicionadas âncoras de confiança (Trust Anchors) via [SWS_CRYPT_50117], opções de validação são definidas via [SWS_CRYPT_50120] e timestamps de referência são armazenados via [SWS_CRYPT_50121]. A verificação hierárquica da cadeia em relação à cadeia de confiança ocorre via [SWS_CRYPT_50122] ou [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests p. 194). Para o registro de revogações de certificados, podem ser importadas Certificate Revocation Lists (CRL) ([SWS_CRYPT_50183]) ou integradas consultas de status de certificado online (OCSP conforme RFC 6960) ao status de validação via [SWS_CRYPT_40626], [SWS_CRYPT_50185] e [SWS_CRYPT_50124] (AUTOSAR AP TR SystemTests p. 194).

Para desacoplar os consumidores de certificados de instâncias individuais de certificados durante trocas de chaves, o manifesto suporta o conceito de CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification p. 657). As aplicações consumidoras carregam todo o grupo de certificados logicamente vinculados por meio de [SWS_CRYPT_50126], enquanto serviços de administração privilegiados podem substituir ou limpar certificados dinamicamente via [SWS_CRYPT_50127] e [SWS_CRYPT_50128] (AUTOSAR AP TPS ManifestSpecification p. 657).

Diagrama de sequência: validação de certificados X.509 com cadeia de certificados, importação de CRL e verificação online de status OCSP. Fontes: [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests p. 194.

Modelagem de manifesto, interfaces de portas e deployment

A integração de recursos criptográficos em uma arquitetura veicular global ocorre de forma declarativa por meio do metamodelo AUTOSAR no manifesto ARXML (AUTOSAR AP TPS ManifestSpecification p. 244). Componentes de software modelam seus requisitos de segurança no nível de projeto através de portas (RPortPrototype), tipificadas por especializações de CryptoInterface: CryptoKeySlotInterface para slots de chave, CryptoCertificateInterface para recursos de certificado e CryptoProviderInterface para acesso a provedores de execução (TPS ManifestSpecification p. 167, AUTOSAR AP TPS ManifestSpecification p. 245). Os atributos das interfaces definem de maneira imutável se permissões de leitura ou escrita são concedidas (writeAccess) e quais tipos de objetos são permitidos (TPS ManifestSpecification p. 168, TPS ManifestSpecification p. 438).

No manifesto de deployment, a configuração de destino (Target Configuration) conecta os protótipos abstratos de porta a recursos físicos concretos da plataforma (AUTOSAR AP TPS ManifestSpecification p. 649). O elemento de metamodelo CryptoKeySlotToPortPrototypeMapping mapeia a porta de um processo para um CryptoModuleInstantiation declarado no CryptoKeySlot da máquina (TPS ManifestSpecification p. 614, TPS ManifestSpecification p. 646). De forma análoga, CryptoCertificateToPortPrototypeMapping associa certificados (TPS ManifestSpecification p. 655). Em tempo de execução, o caminho da porta no manifesto representa o ara::core::InstanceSpecifier, que o código da aplicação passa para funções de carregamento como [SWS_CRYPT_50004] (ManifestSpecification p. 154).

Para interações de plataforma entre clusters funcionais – por exemplo, entre o Communication Management (SecOC, IPsec, TLS) e a pilha de criptografia –, não existem protótipos de porta clássicos (TPS ManifestSpecification p. 861). Aqui, o InstanceSpecifier é formado, em vez disso, por elementos derivados de FunctionalClusterInteractsWithFunctionalClusterMapping, como ComKeyToCryptoKeySlotMapping ou SecOcJobMapping (TPS ManifestSpecification p. 861, TPS ManifestSpecification p. 864, ManifestSpecification p. 411). A proteção de persistência (Persistency Deployment) e os checksums de clusters de software também vinculam suas chaves e provedores por meio desses mapeamentos padronizados de manifesto (TPS ManifestSpecification p. 867, TPS ManifestSpecification p. 896).

Comportamento em caso de erro

O conceito de tratamento de erros do módulo de criptografia segue as rígidas diretrizes da Adaptive Platform para código à prova de falhas e livre de exceções (noexcept) (SWS Cryptography p. 145). Todas as operações síncronas retornam situações de erro por meio do tipo de resultado genérico ara::core::Result<T, ara::core::ErrorCode> (SWS Cryptography p. 208). Os códigos de erro estão ancorados em um domínio de erro próprio, representado por [SWS_CRYPT_19902]; seu nome pode ser consultado via [SWS_CRYPT_19950] e a descrição textual do erro via [SWS_CRYPT_19953]. Para aplicações que utilizam explicitamente o tratamento de exceções, a pilha disponibiliza o tipo de exceção CryptoException ([SWS_CRYPT_19906]) e a função auxiliar [SWS_CRYPT_19954].

Códigos de erro funcionais típicos abrangem violações de contexto como CryptoErrc::kUninitializedContext, quando operações criptográficas são iniciadas antes da chamada de SetKey(), ou CryptoErrc::kInvalidInputSize, quando os buffers de dados de entrada fornecidos não correspondem ao alinhamento de bloco exigido (SWS Cryptography p. 208). Em operações de serialização e conversão, CryptoErrc::kUnknownIdentifier sinaliza valores de argumentos não suportados e CryptoErrc::kIncompatibleArguments combinações incompatíveis de parâmetros (SWS Cryptography p. 145). Ao acessar recursos de chaves, a pilha impede acessos não autorizados retornando kAccessViolation (SWS Cryptography p. 87). Ao analisar extensões de certificado X.509 personalizadas incorretas, o analisador é interrompido com CryptoErrc::kRuntimeFault (SWS Cryptography p. 280, SWS Cryptography p. 356).

Para restabelecer um estado definido no contexto após a ocorrência de um erro e evitar vazamentos de memória ou buffers de streaming travados no daemon, o chamador deve limpar o contexto. Isso é feito de forma direcionada chamando Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), descartando transformações incompletas, ou por meio de Reset() ([SWS_CRYPT_50212]), o que redefine totalmente o contexto para o estado anterior à vinculação da chave (EXP SWArchitecture p. 100).

Evidências mais detalhadas

A especificação do módulo Cryptography baseia-se em uma série de requisitos centrais e documentos de arquitetura, classificados a seguir:

• Pontos de entrada globais e fábricas: as especificações [SWS_CRYPT_20099] (LoadCryptoProvider) e [SWS_CRYPT_40099] (LoadX509Provider) definem o acesso normativo aos dois domínios primários de provedores (SWArchitecture p. 71, SWS Cryptography p. 39).
• Armazenamento de chaves e vinculação de portas: as funções [SWS_CRYPT_50004] (LoadKeySlot) e [SWS_CRYPT_50005] (LoadWriteableKeySlot) implementam de forma vinculativa a interação entre a modelagem de portas no manifesto e o acesso isolado à memória física no KSP (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649).
• Fábricas de primitivas e contextos: o grupo de interfaces em torno de [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx) e [SWS_CRYPT_20757] (CreateVerifierPublicCtx) estabelece a criação dinâmica de máquinas de estados padronizadas para jobs de criptografia (AUTOSAR AP EXP SWArchitecture p. 99, AUTOSAR AP TR SystemTests p. 164).
• Validação X.509 e verificação de revogação: com [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl) e [SWS_CRYPT_50124] (AddOcspResponse), padroniza-se uma cadeia completa de verificação de PKI adequada para o setor automotivo (AUTOSAR AP TR SystemTests p. 194, EXP SWArchitecture p. 116).