AUTOSAR Classic Crypto Services

O cluster agrupa os módulos CSM, CryIf e Crypto Driver para o fornecimento independente de hardware de serviços criptográficos e funções de gestão de chaves na AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. Os jobs criptográficos são priorizados através do CSM, encaminhados no CryIf para canais lógicos e executados de forma síncrona ou assíncrona no Crypto Driver [SWS_CryIf_91003]. Por razões de consistência, as persistências de chaves na NVM ocorrem estritamente apenas após validação bem-sucedida mediante KeySetValid SWS_CryptoDriver p. 37.

mais ›

O cluster de módulos «Crypto Services & Hardware Abstraction» compreende os módulos AUTOSAR Classic Crypto Service Manager (csm), Crypto Interface (cryif) e Crypto Driver (crypto) EXP_UtilizationOfCryptoServices p. 8. Disponibiliza uma camada de abstração independente de hardware para operações criptográficas (entre outras, cifragem, assinaturas, cálculo de MAC e geração de números aleatórios), bem como para uma gestão segura de chaves [SWS_Csm_00982], [SWS_Csm_00984], SWS_CryptoDriver p. 15.

Os pedidos criptográficos são encapsulados como Crypto_JobType, o qual define prioridades, buffers de entrada e saída, bem como modos de operação (Start, Update, Finish para streaming ou SingleCall) [SWS_Csm_01013], [SWS_Csm_01039]. O CSM aceita os pedidos, atribui-os a filas de espera de software e encaminha-os através de CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. O CryIf assume o encaminhamento de canais para os drivers e traduz identificadores de chaves do CSM em IDs de chaves de driver específicas do módulo [SWS_CryIf_00133].

Diagrama de contexto: arquitetura de camadas e cascata de interfaces da stack de criptografia AUTOSAR. Fontes: SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

A Csm_MainFunction() periódica serve para a sincronização de pedidos criptográficos assíncronos, esvaziando as filas de espera e desencadeando os cálculos pendentes [SWS_Csm_00479]. Após a conclusão de um cálculo de hardware assíncrono, o Crypto Driver notifica o CryIf através de CryIf_CallbackNotification(), que repassa a mensagem a Csm_CallbackNotification() e, finalmente, à aplicação chamadora [SWS_CryIf_91013], [SWS_Csm_00970].

Diagrama de sequência: fluxo assíncrono de pedidos criptográficos com enfileiramento e cascata de callbacks. Fontes: [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

A gestão de chaves é realizada através de interfaces padronizadas como Csm_KeyElementSet() e CryIf_KeyElementCopy() sob estrita observância dos direitos de acesso configurados [SWS_Csm_00957], [SWS_CryIf_91015], [SWS_Crypto_00219]. A persistência na NVM é acionada apenas mediante validação explícita através de Crypto_KeySetValid(), evitando assim armazenamentos incompletos de chaves [SWS_Crypto_91014], SWS_CryptoDriver p. 37. Erros como sobrecargas ou estados de chave inválidos são intercetados de forma robusta através de CRYPTO_E_BUSY e CRYPTO_E_KEY_NOT_VALID, respetivamente [SWS_Csm_00018], [SWS_CryIf_91003].

mais ›

1. Arquitetura de sistema & papel do cluster de módulos

O cluster de módulos «Crypto Services & Hardware Abstraction» constitui a base funcional para operações criptográficas, gestão de chaves baseada em software e hardware, bem como comunicação on-board segura na AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. A arquitetura estrutura-se rigorosamente ao longo do modelo de camadas do AUTOSAR em três módulos BSW padronizados: o Crypto Service Manager (csm) na camada de serviços, a Crypto Interface (cryif) na ECU Abstraction Layer e pelo menos um Crypto Driver (crypto) na Microcontroller Abstraction Layer (MCAL) SWS_CryptoDriver p. 15. Esta estrutura em camadas abstrai completamente aplicações de segurança (por exemplo, SecOC, estabelecimentos de ligação TLS e autenticação de diagnóstico UDS) de coprocessadores criptográficos proprietários, tais como Hardware Security Modules (HSM) ou Secure Hardware Extensions (SHE) SWS_SecureOnboardCommunication p. 78.

O Crypto Service Manager (CSM) atua como o principal fornecedor de serviços para componentes de aplicação (SW-Cs) e módulos BSW de nível superior. Ele disponibiliza interfaces de programação padronizadas para algoritmos simétricos e assimétricos (p. ex., AES, RSA), hashing, Message Authentication Codes (MAC), geração de números aleatórios (RNG) e procedimentos AEAD [SWS_Csm_00980], [SWS_Csm_00982], [SWS_Csm_00984], [SWS_Csm_01023]. Além disso, o CSM implementa filas de jobs por software e controla a priorização de pedidos criptográficos paralelos [SWS_Csm_00022], SWS_CryptoServiceManager p. 29.

A Crypto Interface (CryIf), enquanto camada de abstração, disponibiliza uma interface 1:n uniforme entre o CSM e qualquer número de drivers criptográficos. A sua função central é o dispatching: encaminha pedidos para a instância correspondente do Crypto Driver com base em canais lógicos configurados (channelId) e transforma referências lógicas de chaves (cryIfKeyId) em identificadores específicos de driver (cryptoKeyId) [SWS_CryIf_00133], [SWS_CryIf_91003]. O Crypto Driver encapsula a unidade de execução física (Crypto Driver Object) e atende primitivas criptográficas puramente de software ou módulos de segurança de hardware dedicados [SWS_Crypto_00224], SWS_CryptoDriver p. 15.

Diagrama de contexto: arquitetura de camadas e cascata de interfaces da stack de criptografia AUTOSAR. Fontes: SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

2. Interação & caminhos de interação entre os módulos

O processamento de pedidos no cluster ocorre primariamente através do modelo baseado em jobs mediante a estrutura Crypto_JobType [SWS_Csm_01013], AUTOSAR_CP_SWS_CryptoServiceManager p. 21. Um job criptográfico agrega o ID do job, informações de prioridade, referências de chaves, metadados de primitivas e a estrutura Crypto_JobPrimitiveInputOutputType para gestão de ponteiros de parâmetros de entrada, saída e comprimento [SWS_Csm_01012]. O campo de máscara de bits Crypto_OperationModeType (com as flags START, UPDATE, FINISH) controla se um pedido é calculado como uma chamada única contígua (SINGLECALL) ou incrementalmente em modo de streaming [SWS_Csm_01039], [SWS_Csm_01029].

Se uma função de serviço do CSM for chamada de forma síncrona, o CSM verifica o estado do job. Se o driver estiver livre ou o pedido estiver configurado como síncrono, o CSM chama diretamente CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. O CryIf mapeia os IDs de chave e despacha o job para a instância de driver atribuída via Crypto_ProcessJob() [SWS_CryIf_00133]. Em pedidos assíncronos, se o objeto do driver estiver ocupado, o job é colocado na fila de espera do CSM [SWS_Csm_00018], AUTOSAR_CP_SWS_CryptoServiceManager p. 30. Após a conclusão do cálculo assíncrono do driver, o driver aciona CryIf_CallbackNotification() [SWS_CryIf_91013], o CryIf encaminha a mensagem para Csm_CallbackNotification() [SWS_Csm_00970] e, finalmente, o CSM notifica a aplicação requerente através do respetivo callback configurado [SWS_Csm_01044], [SWS_Csm_00928].

Diagrama de sequência: fluxo assíncrono de pedidos criptográficos com enfileiramento e cascata de callbacks. Fontes: [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

Além da execução criptográfica primária, a gestão de chaves constitui um caminho de interação integral do cluster SWS_CryptoDriver p. 24. Uma chave é composta por múltiplos elementos lógicos de chave (como material de chave, vetores de inicialização ou valores de iteração) [SWS_Csm_00954], [SWS_Csm_01022]. Operações como a definição de material de chave via Csm_KeyElementSet(), a cópia mediante Csm_KeyElementCopy() ou a derivação de chaves através de Csm_KeyDerive() são encaminhadas de forma síncrona através do CryIf (CryIf_KeyElementCopy(), CryIf_KeyDerive()) para as funções do driver [SWS_Csm_00957], [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_CryIf_91009]. O acesso aos elementos de chave é rigorosamente monitorizado com base nos direitos de acesso configurados (CRYPTO_RA_ALLOWED, CRYPTO_RA_ENCRYPTED, CRYPTO_RA_INTERNAL_COPY) [SWS_Crypto_00219].

3. Sincronização, reentrância e contextos de tarefas

As operações criptográficas variam drasticamente na sua duração de execução. Enquanto cifras de bloco rápidas ou cálculos de hash podem ser executados de forma síncrona no contexto de tarefa do chamador, cálculos assimétricos (p. ex., geração de assinatura RSA) ou processos de hardware morosos exigem processamento assíncrono [SWS_Csm_00984], [SWS_Csm_00992]. Para o desacoplamento, o CSM disponibiliza a função principal de chamada cíclica Csm_MainFunction() [SWS_Csm_00479]. Esta monitoriza as filas de espera, despacha jobs pendentes para o CryIf e avança as máquinas de estado internas de primitivas assíncronas [SWS_Csm_00019].

Em arquiteturas multinúcleo e multissetor modernas, o CSM suporta múltiplas instâncias Csm_MainFunction_<shortName>() atribuídas a partições dedicadas do SO [SWS_Csm_00479], AUTOSAR_SWS_CryptoServiceManager p. 170. Na execução assíncrona de drivers, os cálculos são terminados ou por polling na MainFunction do driver ou por rotinas de serviço de interrupção (ISR) de motores criptográficos baseados em hardware [SWS_Crypto_00027], [SWS_Crypto_00028]. Por definição, um único Crypto Driver Object pode processar exatamente um job criptográfico de cada vez; um driver com n objetos processa n pedidos verdadeiramente em paralelo [SWS_Crypto_00014], [SWS_Crypto_00117].

Relativamente à reentrância, interfaces de serviço como Csm_MacGenerate() ou CryIf_ProcessJob() são concebidas como reentrantes para jobs distintos, mas proíbem a submissão paralela múltipla da mesma instância de job [SWS_Csm_00016], [SWS_CryIf_91003]. Funções de gestão de chaves como Csm_KeyElementCopy(), CryIf_KeyElementCopy() ou Crypto_KeyCopy() estão implementadas como reentrantes, mas não podem ser aplicadas de forma concorrente ao mesmo identificador de chave de origem (keyId ou cryptoKeyId) para evitar inconsistências de dados e condições de corrida [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_Crypto_00155]. Os drivers de hardware podem utilizar áreas exclusivas internas (Exclusive Areas) para a modificação de áreas de trabalho e registos de chaves internos, prevenindo condições de corrida entre a ISR e o nível de tarefas SWS_CryptoDriver p. 27. Pergunta Q-b1e9578255723a0e (aberta)

Diagrama de atividades: lógica de decisão e desacoplamento por enfileiramento na aceitação de pedidos no CSM. Fontes: AUTOSAR_CP_SWS_CryptoServiceManager p. 30, [SWS_Csm_00017], [SWS_Csm_00018]

4. Ciclos de vida típicos e modos de operação

A inicialização do cluster criptográfico ocorre durante o arranque do BSW por ordem hierárquica. Primeiramente, o EcuM ou o BswM inicializa o nível de driver via Crypto_Init() passando a configuração Crypto_ConfigType [SWS_Crypto_91016], seguido pela camada de interface via CryIf_Init() com CryIf_ConfigType [SWS_CryIf_91118]. Por fim, o CSM é iniciado mediante Csm_Init(), sendo que o seu ponteiro de configuração deve, de acordo com a especificação, ser sempre definido como NULL_PTR [SWS_Csm_00646]. Apenas após a inicialização completa de todas as camadas é permitida a aceitação de pedidos criptográficos ou acessos a chaves [SWS_CryIf_00076], [SWS_Crypto_00196].

Um aspeto central do ciclo de vida da chave é a validação e persistência em memória não volátil (NVM). Após o carregamento de novos valores de chave através de Csm_KeyElementSet(), a chave permanece no estado «incompleto ou desconhecido» [SWS_Csm_00957]. Apenas a chamada explícita de Csm_JobKeySetValid() ou Crypto_KeySetValid() verifica a consistência e altera o estado da chave para válido [SWS_Csm_91027], [SWS_Crypto_91014]. Para chaves persistidas, exclusivamente esta validação aciona o armazenamento na NVM [SWS_Crypto_91026], SWS_CryptoDriver p. 37. Isto previne múltiplos ciclos de escrita fragmentados na NVM e protege contra conjuntos de chaves incompletos SWS_CryptoDriver p. 37. Para a sincronização com o NVRAM Manager, o Crypto Driver utiliza os callbacks Crypto_<vi>_<ai>_NvBlock_ReadFrom_<NvBlock>() e Crypto_<vi>_<ai>_NvBlock_WriteTo_<NvBlock>(), bem como NvM_WriteBlock() [SWS_Crypto_91024], [SWS_Crypto_91025], [SWS_Crypto_91017].

Pedidos de streaming em curso podem, caso necessário, ser interrompidos via Csm_SaveContextJob(), guardados num buffer próprio da aplicação e retomados posteriormente através do restauro de contexto [SWS_Csm_91063], [SWS_Csm_01029]. Antes do encerramento de uma unidade de comando (ECU) ou de uma transição para modos de baixo consumo (low-power), pedidos assíncronos podem ser cancelados de forma controlada via Csm_CancelJob(), pelo que o CryIf remove os jobs das filas de espera do driver e dos canais de hardware através de CryIf_CancelJob() [SWS_Csm_00968], [SWS_CryIf_91014].

5. Tratamento de erros, rastreamento de DET e degradação

O cluster implementa uma estratégia de deteção e defesa contra erros em múltiplos níveis. Com o rastreamento ativo, erros de desenvolvimento são reportados diretamente ao módulo Default Error Tracer (DET) [SWS_Csm_91101], [SWS_Crypto_91017]. Entre os eventos típicos de DET incluem-se chamadas a módulos antes de concluída a inicialização (CRYIF_E_UNINIT, CRYPTO_E_UNINIT), parâmetros de handle ou chave inválidos (CRYIF_E_PARAM_HANDLE, CRYPTO_E_PARAM_HANDLE), bem como a passagem de ponteiros nulos [SWS_CryIf_00076], [SWS_CryIf_00134], [SWS_Crypto_00196], [SWS_Crypto_00217].

Sobrecargas em tempo de execução e escassez de recursos são tratadas deterministicamente através de valores de retorno definidos. Se a fila de espera do CSM para um job assíncrono estiver esgotada, o CSM rejeita o pedido com o código de estado CRYPTO_E_BUSY e gera o erro de tempo de execução CSM_E_QUEUE_FULL [SWS_Csm_00018], [SWS_Csm_01089]. Se um buffer de resultados disponibilizado tiver dimensões insuficientes, o driver cancela a operação com CRYPTO_E_SMALL_BUFFER [SWS_Crypto_00195]. Se um serviço criptográfico referenciar uma chave não inicializada ou explicitamente invalidada (por exemplo, após a chamada de Csm_JobKeySetInvalid() ou Crypto_KeySetInvalid()), os pedidos de serviço falham de forma controlada com CRYPTO_E_KEY_NOT_VALID ou CRYPTO_E_KEY_EMPTY [SWS_Csm_91002], [SWS_CryIf_91003], [SWS_Crypto_91020].

Mecanismos de degradação e fallback são viabilizados no nível do sistema: as aplicações podem verificar o estado de integridade de chaves por meio de Csm_KeyGetStatus() antes do envio de ordens [SWS_Csm_91047], [SWS_CryIf_91012]. Caso um acelerador criptográfico de hardware esteja permanentemente ocupado ou falhe, a configuração de canais CryIf permite uma rota alternativa baseada em software, desde que um driver de software redundante esteja integrado SWS_CryptoDriver p. 15.