clase ara::diag::Authentication

El constructor inicializa de forma síncrona un objeto de la clase manejadora ara::diag::Authentication para gestionar peticiones de autenticación de diagnóstico en un puerto de software [SWS_DM_01124]. El parámetro specifier hace referencia al PortPrototype modelado, que a través de un DiagnosticAuthenticationPortMapping debe estar tipificado obligatoriamente por un DiagnosticAuthenticationInterface [SWS_DM_01124]. A través del parámetro concurrencyType se define si el framework entrega las llamadas a métodos de forma concurrente (kConcurrent) o no segura para subprocesos (kNotConcurrent) [SWS_DM_01124].

Dado que la función está declarada como noexcept, las llamadas erróneas no se notifican mediante excepciones, sino que desencadenan violaciones del framework (Violations) [SWS_DM_01124]:

• InstanceSpecifierMappingIntegrityViolation: el identificador no se puede resolver en el contexto del ejecutable o no hace referencia a ningún PortPrototype [SWS_DM_01124].
• PortInterfaceMappingViolation: el PortPrototype referenciado no está modelado como DiagnosticAuthenticationInterface [SWS_DM_01124].
• ProcessMappingViolation: en tiempo de ejecución no se encuentra ningún proceso modelado adecuado [SWS_DM_01124].
• InstanceSpecifierAlreadyInUseViolation: el InstanceSpecifier ya se ha utilizado para una instancia en el proceso actual [SWS_DM_01124].

El constructor en sí es seguro para subprocesos y seguro frente a excepciones (exception safe) [SWS_DM_01124], mientras que el destructor correspondiente ~Authentication() está especificado como no seguro para subprocesos [SWS_DM_01125]. Inmediatamente después de la instanciación aún no se reenvía ninguna petición de diagnóstico: la aplicación debe llamar primero a Offer() para activar el reenvío para el servicio UDS 0x29 (Authentication con PKI Certificate Exchange, APCE AUTOSAR_AP_SWS_Diagnostics Tab. 4.1 «Limitations of sub-functions of 0x19 ReadDTCInformation») por parte del Diagnostic Manager [SWS_DM_01130]. La validación de certificados se gestiona a continuación mediante VerifyCertificateUnidirectional [SWS_DM_01126], VerifyCertificateBidirectional [SWS_DM_01127] y VerifyOwnership [SWS_DM_01128]. Antes de la destrucción del objeto, el reenvío debe finalizarse con StopOffer() [SWS_DM_01131].

Con el método síncrono Offer() de la clase ara::diag::Authentication ([SWS_DM_01130]), una Adaptive Application registra su manejador de autenticación en Diagnostic Management (DM). De este modo, el DM queda autorizado y en condiciones de reenviar peticiones entrantes a este manejador (AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.1 «Offer»). La función no acepta parámetros de transferencia y señaliza el desenlace de la operación a través del tipo de retorno ara::core::Result<void>.

La llamada está declarada como noexcept y, por tanto, es segura frente a excepciones ([SWS_DM_01130]). Si el registro falla porque el servicio ya se había puesto a disposición previamente para esta instancia, se devuelve el código de error específico DiagOfferErrc::kAlreadyOffered en el objeto Result ([SWS_DM_01130]). Además, la interfaz está especificada como not thread-safe; es de suponer que los accesos paralelos en la misma instancia no deben realizarse sin protección y tienen que sincronizarse en la aplicación. Pregunta Q-51ab72e4e72a7351 (abierta)

En el ciclo de vida del procesamiento de diagnóstico, Offer() se corresponde directamente con la función contraria StopOffer() ([SWS_DM_01131], AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 «StopOffer»), la cual finaliza de nuevo el reenvío de peticiones. Este patrón sigue el enfoque uniforme de provisión de manejadores de diagnóstico, tal como se aplica también, por ejemplo, en ara::diag::CommunicationControl::Offer ([SWS_DM_00809]) o ara::diag::DoIPPowerMode::Offer ([SWS_DM_00735]), donde las peticiones solo pueden procesarse tras un ofrecimiento explícito por parte de la aplicación ([SWS_DM_01525]).

usar

El método StopOffer de la clase ara::diag::Authentication (definido en ara/diag/authentication.h) desactiva el reenvío de mensajes de solicitud por parte del Diagnostic Manager (DM) a la instancia [SWS_DM_01131]. La llamada se ejecuta de forma síncrona, no requiere parámetros de entrada y no tiene valor de retorno AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 «StopOffer».

Tratamiento de errores y seguridad de ejecución

La función está especificada como segura frente a excepciones (noexcept); no se definen códigos de error específicos ni excepciones [SWS_DM_01131].

Concurrencia y restricciones

La operación está designada expresamente como no segura para hilos («not thread-safe») [SWS_DM_01131]. Las llamadas concurrentes en la misma instancia deben sincronizarse mediante la aplicación llamadora.

Interacción y referencia a la arquitectura

El patrón de diseño de StopOffer se utiliza de manera coherente en el Adaptive Diagnostic Manager en diferentes servicios y manejadores, entre ellos SecurityAccess [SWS_DM_00767], CommunicationControl [SWS_DM_00810], DownloadService [SWS_DM_00793] y EcuResetRequest [SWS_DM_01017]. Aunque la denominación se basa en la puesta a disposición de servicios en ara::com, se trata de una implementación específica de diagnóstico AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 «Monitors». Interpretación: con anterioridad a la desactivación mediante StopOffer, es probable que la instancia haya estado aceptando activamente solicitudes a través de una función de ofrecimiento. Pregunta Q-da990416e53707ed (abierta)

El método de retrollamada virtual puro VerifyCertificateBidirectional de la interfaz ara::diag::Authentication ([SWS_DM_01127]) es llamado por el Diagnostic Server en cuanto llega una solicitud de diagnóstico para el servicio UDS 0x29 (Authentication) con la subfunción 0x02 (verifyCertificateBidirectional) y se han superado con éxito las comprobaciones iniciales ([SWS_DM_01235], AUTOSAR_AP_SWS_Diagnostics §7.3.2.8.11.3 «Service 0x29 – verifyCertificateBidirectional (0x02)»).

Uso y semántica:\nEl servidor transfiere la configuración de comunicación así como los datos de certificado y desafío recibidos del tester a través de communicationConfiguration, clientCertificate y clientChallenge junto con metaInfo y el cancellationHandler ([SWS_DM_01127], [SWS_DM_01235]). Los búferes de los spans de entrada siguen siendo válidos hasta que el ara::core::Future devuelto se cumpla a través del promise correspondiente o se cancele el proceso ([SWS_DM_01127]). De forma asíncrona, el método devuelve al Diagnostic Server una 4-tupla compuesta por desafío del servidor, certificado del servidor, prueba de propiedad (proof-of-ownership) calculada y la clave pública efímera del servidor ([SWS_DM_01127]).

Cancelación y concurrencia:\nA través del cancellationHandler, la aplicación puede sondear el estado actual mediante IsCanceled o registrar mediante SetNotifier una función de notificación para la cancelación de conexión ([SWS_DM_01127]). La interfaz está definida como noexcept y puede llamarse de forma reentrante respecto a solicitudes de diferentes clientes ([SWS_DM_01127]). Si la implementación debe ser segura frente a hilos, se determina a través del ConcurrencyType transferido en el constructor ([SWS_DM_01127]).

Tratamiento de errores e interacción:\nEn caso de error, la aplicación devuelve un NRC adecuado conforme a ISO 14229-1 a través de DiagUdsNrcErrc; los valores de retorno negativos son procesados por separado por el Diagnostic Server ([SWS_DM_01127], [SWS_DM_01236]). Dentro de la autenticación UDS ([SWS_DM_01226]), la configuración de esta subfunción constituye un requisito previo necesario si DiagnosticProofOfOwnership está configurada ([SWS_DM_01227], [SWS_DM_01228]).

El método de retrollamada VerifyCertificateUnidirectional de la clase ara::diag::Authentication es llamado por la instancia de servidor de diagnóstico en cuanto se recibe y se precomprueba con éxito una solicitud para el servicio UDS 0x29 con la subfunción verifyCertificateUnidirectional (0x01) (SWS Diagnostics §7.3.2.8.11.2 «Service 0x29 – verifyCertificateUnidirectional (0x01)», [SWS_DM_01230]). Implementa la autenticación unidireccional a través de intercambio de certificados PKI conforme a ISO 14229-1 ([SWS_DM_01226]).

Como parámetros se transfieren la configuración de comunicación (communicationConfiguration), el certificado de cliente (clientCertificate) y el desafío de cliente (clientChallenge), así como metainformación y un CancellationHandler ([SWS_DM_01126]). Los spans transferidos siguen siendo válidos hasta que se cumpla el ara::core::Future devuelto o se cancele el procesamiento a través del manejador. El método devuelve asíncronamente una tupla compuesta por el desafío de servidor generado y la clave pública efímera del servidor ([SWS_DM_01126]).

Si se produce un error durante la validación, se debe finalizar el Future con un código de respuesta negativa (NRC) adecuado a través de DiagUdsNrcErrc ([SWS_DM_01126]).

La función está especificada como exception safe y puede ser llamada de forma reentrante para solicitudes de diferentes clientes de diagnóstico ([SWS_DM_01126]). La seguridad frente a hilos es condicional; si la implementación debe ser thread-safe lo determina el ConcurrencyType establecido en el constructor ([SWS_DM_01126]). En el flujo global, la configuración de esta comprobación es un requisito obligatorio en caso de configurarse la subfunción DiagnosticProofOfOwnership ([SWS_DM_01227]).

Uso y contexto de llamada

El método puramente virtual VerifyOwnership de la clase ara::diag::Authentication es invocado por el Diagnostic Server tan pronto como se recibe una solicitud de autenticación del servicio UDS 0x29 con la subfunción proofOfOwnership (0x03) y las comprobaciones preparatorias han concluido con éxito [SWS_DM_01240]. La tarea de la implementación consiste en verificar la prueba de propiedad (Proof of Ownership) transmitida por el tester frente al challenge generado por el servidor, basándose en la clave pública del certificado de cliente intercambiado previamente [SWS_DM_01128].

En el momento de la invocación, el Diagnostic Server transfiere los datos criptográficos de entrada relevantes, así como objetos de contexto AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.5 «VerifyOwnership»:

• clientPOWN: Contiene el Proof of Ownership proporcionado por el tester de diagnóstico para el challenge previo del servidor.
• clientEphemeralPublicKey: La clave pública efímera del cliente para el acuerdo de claves Diffie-Hellman según ISO 14229-1:2020.
• metaInfo: Metainformación de la solicitud de diagnóstico actual.
• cancellationHandler: Permite consultar una eventual cancelación (cancellationHandler.IsCanceled), así como registrar una función de notificación (cancellationHandler.SetNotifier).

La función opera de forma asíncrona y devuelve un ara::core::Future que, en caso de éxito, proporciona la información de Session-Key como vector de bytes [SWS_DM_01128].

Manejo de errores

Si la comprobación de propiedad no puede realizarse con éxito, la aplicación establece un código de retorno negativo de UDS (NRC) adecuado según ISO 14229-1 a través de DiagUdsNrcErrc en el future devuelto [SWS_DM_01128]. Si el método devuelve un código de error definido de este tipo, el Diagnostic Server envía una Negative Response con el NRC correspondiente al cliente [SWS_DM_01241].

Concurrencia y condiciones de contorno

La interfaz está definida como noexcept. En lo relativo a la seguridad de hilos, el comportamiento se considera condicional (conditional): si el método debe implementarse de forma segura para hilos queda determinado por el ConcurrencyType especificado durante la construcción de la instancia [SWS_DM_01128]. Para los búferes clientPOWN y clientEphemeralPublicKey se garantiza que su área de memoria permanezca válida hasta que se cumpla la promise o se cancele el procesamiento mediante el cancellationHandler [SWS_DM_01128].

El destructor virtual ~Authentication() finaliza el ciclo de vida de una instancia de la clase ara::diag::Authentication y libera sus recursos [SWS_DM_01125]. El método está declarado en el archivo de cabecera #include "ara/diag/authentication.h" del módulo Diagnostics AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 «Destructor».

La función no toma ningún parámetro, no devuelve ningún valor de retorno y se llama de forma síncrona durante la destrucción del objeto [SWS_DM_01125]. Mediante la calificación como virtual se garantiza que, en caso de eliminación polimórfica a través de punteros o referencias a clases base, también se limpien debidamente los recursos de clases derivadas.

Respecto al tratamiento de errores, el método está especificado como exception safe y lleva el especificador noexcept [SWS_DM_01125]. No se devuelven códigos de error o de estado, y se garantiza que no salgan excepciones C++ al exterior.

En cuanto a la concurrencia, ~Authentication() está clasificado como not thread-safe [SWS_DM_01125]. Por lo tanto, la destrucción en ningún caso debe realizarse simultáneamente con otras llamadas a métodos de la misma instancia. Interpretación: La aplicación utilizadora debería estar obligada a concluir todos los procesos de autenticación o de diagnóstico en curso antes de la destrucción y a proteger externamente la llamada frente a accesos paralelos. Pregunta Q-41b1c115c1056759 (abierta) El destructor implementa el requisito superior RS_Diag_04251 AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 «Destructor».