classe ara::diag::Authentication

O construtor inicializa de forma síncrona um objeto da classe de handler ara::diag::Authentication para o processamento de pedidos de autenticação de diagnóstico numa porta de software [SWS_DM_01124]. O parâmetro specifier remete para o PortPrototype modelado, que tem de ser obrigatoriamente tipificado através de um DiagnosticAuthenticationPortMapping por um DiagnosticAuthenticationInterface [SWS_DM_01124]. Através do parâmetro concurrencyType define-se se o framework entrega chamadas de método de forma concorrente (kConcurrent) ou não segura para threads (kNotConcurrent) [SWS_DM_01124].

Como a função está declarada como noexcept, chamadas incorretas não são reportadas através de exceções, mas desencadeiam violações de framework (violations) [SWS_DM_01124]:

• InstanceSpecifierMappingIntegrityViolation: O identificador não pode ser resolvido no contexto do executável ou não referencia um PortPrototype [SWS_DM_01124].
• PortInterfaceMappingViolation: O PortPrototype referenciado não está modelado como DiagnosticAuthenticationInterface [SWS_DM_01124].
• ProcessMappingViolation: Em tempo de execução não é encontrado nenhum processo modelado correspondente [SWS_DM_01124].
• InstanceSpecifierAlreadyInUseViolation: O InstanceSpecifier já foi utilizado para uma instância no processo atual [SWS_DM_01124].

O próprio construtor é seguro para threads e seguro contra exceções (exception safe) [SWS_DM_01124], enquanto o respetivo destrutor ~Authentication() está especificado como não seguro para threads [SWS_DM_01125]. Imediatamente após a instanciação, ainda não são encaminhados pedidos de diagnóstico: a aplicação tem primeiro de chamar Offer() para ativar o encaminhamento para o serviço UDS 0x29 (Authentication com PKI Certificate Exchange, APCE AUTOSAR_AP_SWS_Diagnostics Tab. 4.1 «Limitations of sub-functions of 0x19 ReadDTCInformation») por parte do Diagnostic Manager [SWS_DM_01130]. A validação de certificados é seguidamente processada através de VerifyCertificateUnidirectional [SWS_DM_01126], VerifyCertificateBidirectional [SWS_DM_01127] e VerifyOwnership [SWS_DM_01128]. Antes da destruição do objeto, o encaminhamento deve ser encerrado com StopOffer() [SWS_DM_01131].

Com o método síncrono Offer() da classe ara::diag::Authentication ([SWS_DM_01130]), uma Adaptive Application registra seu handler de autenticação junto ao Diagnostic Management (DM). Com isso, o DM é autorizado e capacitado a encaminhar requisições recebidas para este handler (AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.1 «Offer»). A função não recebe parâmetros de entrada e sinaliza o resultado da operação por meio do tipo de retorno ara::core::Result<void>.

A chamada é declarada como noexcept e, portanto, segura contra exceções ([SWS_DM_01130]). Se o registro falhar porque o serviço já foi disponibilizado anteriormente para esta instância, o código de erro específico DiagOfferErrc::kAlreadyOffered é retornado no objeto Result ([SWS_DM_01130]). Além disso, a interface é especificada como not thread-safe; acessos paralelos na mesma instância presumivelmente não devem ocorrer sem proteção e devem ser sincronizados no lado da aplicação. Pergunta Q-51ab72e4e72a7351 (aberta)

No ciclo de vida do processamento de diagnóstico, Offer() corresponde diretamente à função oposta StopOffer() ([SWS_DM_01131], AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 «StopOffer»), que encerra novamente o encaminhamento de requisições. Esse padrão segue a abordagem uniforme de disponibilização de handlers de diagnóstico, como também é aplicada, por exemplo, em ara::diag::CommunicationControl::Offer ([SWS_DM_00809]) ou ara::diag::DoIPPowerMode::Offer ([SWS_DM_00735]), nos quais requisições só podem ser processadas após a oferta explícita pela aplicação ([SWS_DM_01525]).

usar

O método StopOffer da classe ara::diag::Authentication (definido em ara/diag/authentication.h) desativa o encaminhamento de mensagens de solicitação pelo Diagnostic Manager (DM) para a instância [SWS_DM_01131]. A chamada é executada de forma síncrona, não requer parâmetros de passagem e não possui valor de retorno AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 «StopOffer».

Tratamento de erros e segurança de execução

A função é especificada como segura contra exceções (noexcept); códigos de erro específicos ou exceções não estão definidos [SWS_DM_01131].

Simultaneidade e restrições

A operação é expressamente indicada como não segura para threads («not thread-safe») [SWS_DM_01131]. Chamadas concorrentes na mesma instância devem ser sincronizadas pela aplicação chamadora.

Interação e relação arquitetural

O padrão de projeto de StopOffer é utilizado de forma consistente no Adaptive Diagnostic Manager através de diferentes serviços e handlers, entre eles SecurityAccess [SWS_DM_00767], CommunicationControl [SWS_DM_00810], DownloadService [SWS_DM_00793] e EcuResetRequest [SWS_DM_01017]. Embora a nomenclatura seja baseada no fornecimento de serviços em ara::com, trata-se de uma implementação específica de diagnóstico AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 «Monitors». Interpretação: antes da desativação por meio de StopOffer, a instância provavelmente terá recebido solicitações ativamente através de uma função de disponibilização. Pergunta Q-da990416e53707ed (aberta)

O método de callback puramente virtual VerifyCertificateBidirectional da interface ara::diag::Authentication ([SWS_DM_01127]) é chamado pelo Diagnostic Server assim que uma solicitação de diagnóstico para o serviço UDS 0x29 (Authentication) com a subfunção 0x02 (verifyCertificateBidirectional) chega e as verificações iniciais foram concluídas com sucesso ([SWS_DM_01235], AUTOSAR_AP_SWS_Diagnostics §7.3.2.8.11.3 «Service 0x29 – verifyCertificateBidirectional (0x02)»).

Uso e semântica:\nO servidor passa a configuração de comunicação, bem como os dados de certificado e de challenge recebidos do testador através de communicationConfiguration, clientCertificate e clientChallenge juntamente com metaInfo e o cancellationHandler ([SWS_DM_01127], [SWS_DM_01235]). Os buffers dos spans de entrada permanecem válidos até que o ara::core::Future retornado seja cumprido por meio do Promise associado ou a operação seja cancelada ([SWS_DM_01127]). De forma assíncrona, o método retorna uma 4-tupla composta por challenge do servidor, certificado do servidor, Proof-of-Ownership calculado e a Ephemeral Public Key do servidor para o Diagnostic Server ([SWS_DM_01127]).

Cancelamento e simultaneidade:\nAtravés do cancellationHandler, a aplicação pode consultar o status atual por meio de sondagem (polling) via IsCanceled ou registrar uma função de notificação para a desconexão por meio de SetNotifier ([SWS_DM_01127]). A interface é definida como noexcept e pode ser chamada de forma reentrante com relação a solicitações de diferentes clientes ([SWS_DM_01127]). Se a implementação deve ser segura para threads é determinado através do ConcurrencyType passado no construtor ([SWS_DM_01127]).

Tratamento de erros e interação:\nEm caso de erro, a aplicação retorna um NRC apropriado em conformidade com a ISO 14229-1 através de DiagUdsNrcErrc; valores de retorno negativos são processados separadamente pelo Diagnostic Server ([SWS_DM_01127], [SWS_DM_01236]). Dentro da autenticação UDS ([SWS_DM_01226]), a configuração desta subfunção constitui um pré-requisito necessário se DiagnosticProofOfOwnership estiver configurado ([SWS_DM_01227], [SWS_DM_01228]).

O método de callback VerifyCertificateUnidirectional da classe ara::diag::Authentication é chamado pela instância do Diagnostic Server assim que uma solicitação para o serviço UDS 0x29 com a subfunção verifyCertificateUnidirectional (0x01) for recebida e pré-verificada com sucesso (SWS Diagnostics §7.3.2.8.11.2 «Service 0x29 – verifyCertificateUnidirectional (0x01)», [SWS_DM_01230]). Ele realiza a autenticação unidirecional via troca de certificados PKI em conformidade com a ISO 14229-1 ([SWS_DM_01226]).

Como parâmetros, são passados a configuração de comunicação (communicationConfiguration), o certificado de cliente (clientCertificate) e o challenge de cliente (clientChallenge), bem como metainformações e um CancellationHandler ([SWS_DM_01126]). Os spans passados permanecem válidos até que o ara::core::Future retornado seja cumprido ou o processamento seja cancelado através do manipulador. O método retorna de forma assíncrona uma tupla composta pelo challenge do servidor gerado e pela chave pública efêmera do servidor ([SWS_DM_01126]).

Se ocorrer um erro durante a validação, o Future deve ser encerrado com um código de resposta negativo (NRC) apropriado através de DiagUdsNrcErrc ([SWS_DM_01126]).

A função é especificada como exception safe e pode ser chamada de forma reentrante para solicitações de diferentes clientes de diagnóstico ([SWS_DM_01126]). A segurança de thread é condicional; se a implementação deve ser thread-safe é determinado pelo ConcurrencyType definido no construtor ([SWS_DM_01126]). No fluxo geral, a configuração desta verificação é um pré-requisito obrigatório caso a subfunção DiagnosticProofOfOwnership seja configurada ([SWS_DM_01227]).

Utilização e contexto de chamada

O método puramente virtual VerifyOwnership da classe ara::diag::Authentication é chamado pelo Diagnostic Server assim que uma solicitação de autenticação do serviço UDS 0x29 com a subfunção proofOfOwnership (0x03) foi recebida e as verificações preparatórias foram bem-sucedidas [SWS_DM_01240]. A tarefa da implementação é verificar a prova de posse (Proof of Ownership) transmitida pelo testador com base na chave pública do certificado de cliente previamente trocado contra o challenge gerado pelo servidor [SWS_DM_01128].

Na chamada, o Diagnostic Server passa os dados de entrada criptográficos relevantes, bem como objetos de contexto AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.5 «VerifyOwnership»:

• clientPOWN: Contém a Proof of Ownership fornecida pelo testador de diagnóstico para o challenge anterior do servidor.
• clientEphemeralPublicKey: A chave pública efêmera do cliente para o acordo de chaves Diffie-Hellman de acordo com a ISO 14229-1:2020.
• metaInfo: Metainformações da solicitação de diagnóstico atual.
• cancellationHandler: Permite consultar um eventual cancelamento (cancellationHandler.IsCanceled), bem como registrar uma função de notificação (cancellationHandler.SetNotifier).

A função opera de forma assíncrona e retorna um ara::core::Future, que, em caso de sucesso, disponibiliza as informações de Session Key como um vetor de bytes [SWS_DM_01128].

Tratamento de erros

Se a verificação de posse não puder ser realizada com sucesso, a aplicação define um valor de retorno negativo de UDS (NRC) adequado conforme a ISO 14229-1 por meio de DiagUdsNrcErrc no Future retornado [SWS_DM_01128]. Se o método retornar tal código de erro definido, o Diagnostic Server envia uma Negative Response com o respectivo NRC ao cliente [SWS_DM_01241].

Simultaneidade e condições marginais

A interface está definida como noexcept. Em relação à segurança de threads, o comportamento é considerado condicional (conditional): se o método precisa ser implementado de forma segura para threads, é determinado pelo ConcurrencyType especificado na construção da instância [SWS_DM_01128]. Para os buffers clientPOWN e clientEphemeralPublicKey, garante-se que a sua área de memória permaneça válida até que o Promise seja cumprido ou o processamento seja cancelado por meio do cancellationHandler [SWS_DM_01128].

O destruidor virtual ~Authentication() conclui o ciclo de vida de uma instância da classe ara::diag::Authentication e libera seus recursos [SWS_DM_01125]. O método está declarado no arquivo de cabeçalho #include "ara/diag/authentication.h" do módulo Diagnostics AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 «Destructor».

A função não recebe parâmetros, não fornece valor de retorno e é chamada de forma síncrona durante a destruição do objeto [SWS_DM_01125]. A qualificação como virtual garante que, em caso de exclusão polimórfica através de ponteiros ou referências para classes base, os recursos de classes derivadas também sejam devidamente limpos.

Em relação ao tratamento de erros, o método é especificado como exception safe e traz o especificador noexcept [SWS_DM_01125]. Códigos de erro ou de status não são retornados e garante-se que nenhuma exceção C++ se propague externamente.

Quanto à simultaneidade, ~Authentication() é classificado como not thread-safe [SWS_DM_01125]. A destruição não deve, portanto, sob hipótese alguma ocorrer simultaneamente com outras chamadas de método da mesma instância. Interpretação: A aplicação utilizadora provavelmente deve ser obrigada a concluir todos os processos de autenticação ou diagnóstico em andamento antes da destruição e proteger a chamada externamente contra acessos paralelos. Pergunta Q-41b1c115c1056759 (aberta) O destruidor implementa o requisito de nível superior RS_Diag_04251 AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 «Destructor».