AUTOSAR Classic Crypto Services

El cluster agrupa los módulos CSM, CryIf y Crypto Driver para proporcionar de forma independiente del hardware servicios criptográficos y funciones de gestión de claves en la AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. Los trabajos criptográficos se priorizan a través del CSM, se enrutan en el CryIf hacia canales lógicos y se ejecutan de manera síncrona o asíncrona en el Crypto Driver [SWS_CryIf_91003]. Por razones de coherencia, las persistencias de claves en la NVM se realizan estrictamente tras una validación correcta mediante KeySetValid SWS_CryptoDriver p. 37.

más ›

El cluster de módulos «Crypto Services & Hardware Abstraction» comprende los módulos de AUTOSAR Classic Crypto Service Manager (csm), Crypto Interface (cryif) y Crypto Driver (crypto) EXP_UtilizationOfCryptoServices p. 8. Proporciona una capa de abstracción independiente del hardware para operaciones criptográficas (entre otras, cifrado, firmas, cálculo de MAC y generación de números aleatorios), así como para una gestión segura de claves [SWS_Csm_00982], [SWS_Csm_00984], SWS_CryptoDriver p. 15.

Las solicitudes criptográficas se encapsulan como Crypto_JobType, el cual define prioridades, búferes de entrada y salida, así como modos de operación (Start, Update, Finish para streaming o SingleCall) [SWS_Csm_01013], [SWS_Csm_01039]. El CSM acepta trabajos, los asigna a colas de software y los reenvía a través de CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. El CryIf asume el enrutamiento de canales hacia los controladores y traduce los identificadores de clave del CSM a ID de clave de controlador específicos del módulo [SWS_CryIf_00133].

Diagrama de contexto: arquitectura de capas y cascada de interfaces de la pila criptográfica de AUTOSAR. Fuentes: SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

Para la sincronización de trabajos criptográficos asíncronos sirve la Csm_MainFunction() periódica, la cual vacía las colas e inicia los cálculos pendientes [SWS_Csm_00479]. Tras finalizar un cálculo asíncrono por hardware, el Crypto Driver notifica al CryIf mediante CryIf_CallbackNotification(), el cual transmite el aviso a Csm_CallbackNotification() y, en última instancia, a la aplicación llamante [SWS_CryIf_91013], [SWS_Csm_00970].

Diagrama de secuencias: flujo de trabajo criptográfico asíncrono con encolamiento y cascada de retrollamadas. Fuentes: [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

La gestión de claves se realiza a través de interfaces estandarizadas como Csm_KeyElementSet() y CryIf_KeyElementCopy() bajo el cumplimiento estricto de los derechos de acceso configurados [SWS_Csm_00957], [SWS_CryIf_91015], [SWS_Crypto_00219]. La persistencia en la NVM solo se activa tras una validación explícita mediante Crypto_KeySetValid(), con lo que se evitan almacenamientos incompletos de claves [SWS_Crypto_91014], SWS_CryptoDriver p. 37. Errores como sobrecargas o estados de clave no válidos se interceptan de manera robusta mediante CRYPTO_E_BUSY o CRYPTO_E_KEY_NOT_VALID [SWS_Csm_00018], [SWS_CryIf_91003].

más ›

1. Arquitectura del sistema y rol del clúster de módulos

El cluster de módulos «Crypto Services & Hardware Abstraction» constituye el fundamento funcional para operaciones criptográficas, gestión de claves asistida por software y hardware, y comunicación segura a bordo en la AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. La arquitectura se estructura estrictamente a lo largo del modelo de capas de AUTOSAR en tres módulos BSW estandarizados: el Crypto Service Manager (csm) en la capa de servicios, el Crypto Interface (cryif) en la ECU Abstraction Layer y al menos un Crypto Driver (crypto) en la Microcontroller Abstraction Layer (MCAL) SWS_CryptoDriver p. 15. Esta estructura en capas abstrae por completo las aplicaciones de seguridad (por ejemplo, SecOC, establecimientos de conexión TLS y autenticación de diagnóstico UDS) de coprocesadores criptográficos propietarios, como Hardware Security Modules (HSM) o Secure Hardware Extensions (SHE) SWS_SecureOnboardCommunication p. 78.

El Crypto Service Manager (CSM) actúa como proveedor principal de servicios para componentes de aplicación (SW-Cs) y módulos BSW de nivel superior. Proporciona interfaces de programación estandarizadas para algoritmos simétricos y asimétricos (p. ej., AES, RSA), hashing, códigos de autenticación de mensajes (MAC), generación de números aleatorios (RNG) y procedimientos AEAD [SWS_Csm_00980], [SWS_Csm_00982], [SWS_Csm_00984], [SWS_Csm_01023]. Asimismo, el CSM implementa colas de trabajos por software y controla la priorización de trabajos criptográficos paralelos [SWS_Csm_00022], SWS_CryptoServiceManager p. 29.

El Crypto Interface (CryIf), como capa de abstracción, proporciona una interfaz homogénea 1:n entre el CSM y cualquier cantidad de controladores criptográficos. Su tarea central es el despacho (dispatching): reenvía trabajos en función de canales lógicos configurados (channelId) a la instancia de Crypto Driver correspondiente y transforma referencias de clave lógicas (cryIfKeyId) en identificadores específicos del controlador (cryptoKeyId) [SWS_CryIf_00133], [SWS_CryIf_91003]. El Crypto Driver encapsula la unidad de ejecución física (Crypto Driver Object) y atiende primitivas criptográficas puramente de software o módulos de seguridad de hardware específicos [SWS_Crypto_00224], SWS_CryptoDriver p. 15.

Diagrama de contexto: arquitectura de capas y cascada de interfaces de la pila criptográfica de AUTOSAR. Fuentes: SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

2. Interacción y rutas de comunicación entre los módulos

El procesamiento de trabajos dentro del cluster se realiza principalmente a través del modelo basado en trabajos mediante la estructura Crypto_JobType [SWS_Csm_01013], AUTOSAR_CP_SWS_CryptoServiceManager p. 21. Un trabajo criptográfico agrupa el ID de trabajo, información de prioridad, referencias de clave, metadatos de la primitiva y la estructura Crypto_JobPrimitiveInputOutputType para la gestión de punteros de parámetros de entrada, salida y longitud [SWS_Csm_01012]. Mediante el campo de máscara de bits Crypto_OperationModeType (con las banderas START, UPDATE, FINISH) se controla si un trabajo se calcula como una llamada única coherente (SINGLECALL) o de forma incremental en modo de streaming [SWS_Csm_01039], [SWS_Csm_01029].

Si se llama síncronamente a una función de servicio del CSM, el CSM comprueba el estado del trabajo. Si el controlador está libre o el trabajo está configurado como síncrono, el CSM llama directamente a CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. El CryIf mapea los ID de clave y despacha el trabajo a la instancia de controlador asignada mediante Crypto_ProcessJob() [SWS_CryIf_00133]. En solicitudes asíncronas, si el objeto del controlador está ocupado, el trabajo se encola en la cola del CSM [SWS_Csm_00018], AUTOSAR_CP_SWS_CryptoServiceManager p. 30. Tras finalizar el cálculo asíncrono del controlador, el controlador dispara CryIf_CallbackNotification() [SWS_CryIf_91013], el CryIf reenvía la notificación a Csm_CallbackNotification() [SWS_Csm_00970] y, finalmente, el CSM notifica a la aplicación solicitante mediante su retrollamada configurada [SWS_Csm_01044], [SWS_Csm_00928].

Diagrama de secuencias: flujo de trabajo criptográfico asíncrono con encolamiento y cascada de retrollamadas. Fuentes: [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

Junto a la ejecución criptográfica principal, la gestión de claves constituye una ruta de interacción integral del cluster SWS_CryptoDriver p. 24. Una clave consta de varios elementos de clave lógicos (como material de clave, vectores de inicialización o valores de iteración) [SWS_Csm_00954], [SWS_Csm_01022]. Operaciones como el establecimiento de material de clave mediante Csm_KeyElementSet(), la copia mediante Csm_KeyElementCopy() o la derivación de claves mediante Csm_KeyDerive() se reenvían síncronamente a través del CryIf (CryIf_KeyElementCopy(), CryIf_KeyDerive()) a las funciones del controlador [SWS_Csm_00957], [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_CryIf_91009]. En este proceso, el acceso a los elementos de clave se supervisa estrictamente en función de los derechos de acceso configurados (CRYPTO_RA_ALLOWED, CRYPTO_RA_ENCRYPTED, CRYPTO_RA_INTERNAL_COPY) [SWS_Crypto_00219].

3. Sincronización, reentrancia y contextos de tareas

Las operaciones criptográficas varían drásticamente en su duración de ejecución. Mientras que los cifrados por bloques rápidos o los cálculos de hash pueden ejecutarse síncronamente en el contexto de tarea de la entidad llamante, los cálculos asimétricos (p. ej., la generación de firmas RSA) o los procesos de hardware prolongados requieren un procesamiento asíncrono [SWS_Csm_00984], [SWS_Csm_00992]. Para el desacoplamiento, el CSM proporciona la función principal llamada cíclicamente Csm_MainFunction() [SWS_Csm_00479]. Esta supervisa las colas, despacha trabajos pendientes al CryIf e impulsa las máquinas de estados internas de primitivas asíncronas [SWS_Csm_00019].

En arquitecturas multinúcleo y multisector modernas, el CSM admite múltiples instancias Csm_MainFunction_<shortName>(), que se asignan a particiones de OS dedicadas [SWS_Csm_00479], AUTOSAR_SWS_CryptoServiceManager p. 170. En la ejecución asíncrona de controladores, los cálculos se finalizan bien por sondeo en la MainFunction del controlador o bien mediante rutinas de servicio de interrupción (ISR) de motores criptográficos basados en hardware [SWS_Crypto_00027], [SWS_Crypto_00028]. Por definición, un único Crypto Driver Object puede procesar exactamente un trabajo criptográfico a la vez; un controlador con n objetos procesa n trabajos de forma verdaderamente paralela [SWS_Crypto_00014], [SWS_Crypto_00117].

En cuanto a la reentrancia, las interfaces de servicio como Csm_MacGenerate() o CryIf_ProcessJob() están diseñadas para ser reentrantes para diferentes jobs, pero prohíben la asignación múltiple en paralelo de la misma instancia de job [SWS_Csm_00016], [SWS_CryIf_91003]. Las funciones de gestión de claves como Csm_KeyElementCopy(), CryIf_KeyElementCopy() o Crypto_KeyCopy() están implementadas como reentrantes, pero no deben aplicarse de forma concurrente al mismo identificador de clave de origen (keyId o cryptoKeyId) para evitar inconsistencias de datos y condiciones de carrera [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_Crypto_00155]. Los controladores de hardware podrían utilizar áreas exclusivas internas (Exclusive Areas) para la modificación de áreas de trabajo internas y registros de claves con el fin de interceptar condiciones de carrera entre la ISR y el nivel de tarea SWS_CryptoDriver p. 27. Pregunta Q-b1e9578255723a0e (abierta)

Diagrama de actividades: Lógica de decisión y desacoplamiento de encolado en la aceptación de órdenes en el CSM. Fuentes: AUTOSAR_CP_SWS_CryptoServiceManager p. 30, [SWS_Csm_00017], [SWS_Csm_00018]

4. Ciclos de vida típicos y modos de funcionamiento

La inicialización del clúster de criptografía se realiza durante el arranque del BSW en orden jerárquico. En primer lugar, el EcuM o BswM inicializa el nivel de controlador a través de Crypto_Init() transfiriendo la configuración Crypto_ConfigType [SWS_Crypto_91016], seguido de la capa de interfaz a través de CryIf_Init() con CryIf_ConfigType [SWS_CryIf_91118]. Por último, se inicia el CSM mediante Csm_Init(), debiendo configurarse su puntero de configuración según la especificación siempre a NULL_PTR [SWS_Csm_00646]. Solo tras la inicialización completa de todas las capas se permite la aceptación de órdenes criptográficas o accesos a claves [SWS_CryIf_00076], [SWS_Crypto_00196].

Un aspecto central del ciclo de vida de las claves es la validación y persistencia en memoria no volátil (NVM). Tras cargar nuevos valores de clave a través de Csm_KeyElementSet(), la clave permanece en el estado «incompleta o desconocida» [SWS_Csm_00957]. Solo la llamada explícita a Csm_JobKeySetValid() o Crypto_KeySetValid() comprueba la coherencia y cambia el estado de la clave a válido [SWS_Csm_91027], [SWS_Crypto_91014]. En claves persistidas, únicamente esta validación desencadena el almacenamiento en la NVM [SWS_Crypto_91026], SWS_CryptoDriver p. 37. Esto evita múltiples ciclos de escritura fragmentados en la NVM y protege contra conjuntos de claves incompletos SWS_CryptoDriver p. 37. Para la sincronización con el NVRAM Manager, el Crypto Driver se sirve de las callbacks Crypto_<vi>_<ai>_NvBlock_ReadFrom_<NvBlock>() y Crypto_<vi>_<ai>_NvBlock_WriteTo_<NvBlock>(), así como de NvM_WriteBlock() [SWS_Crypto_91024], [SWS_Crypto_91025], [SWS_Crypto_91017].

Las órdenes de streaming en curso pueden interrumpirse en caso necesario mediante Csm_SaveContextJob(), asegurarse en un búfer propio de la aplicación y continuarse más adelante mediante el restablecimiento del contexto [SWS_Csm_91063], [SWS_Csm_01029]. Antes de un apagado de la ECU o de una transición a modos de bajo consumo (Low-Power), las órdenes asíncronas pueden cancelarse de forma controlada a través de Csm_CancelJob(), con lo cual el CryIf elimina los jobs de las colas de controladores y canales de hardware mediante CryIf_CancelJob() [SWS_Csm_00968], [SWS_CryIf_91014].

5. Tratamiento de errores, rastreo de DET y degradación

El clúster implementa una estrategia de detección y defensa contra errores de varios niveles. Los errores de desarrollo se notifican directamente al módulo Default Error Tracer (DET) cuando el trazado está activado [SWS_Csm_91101], [SWS_Crypto_91017]. Entre los eventos típicos de DET se incluyen llamadas a módulos antes de la inicialización (CRYIF_E_UNINIT, CRYPTO_E_UNINIT), parámetros de handle o clave no válidos (CRYIF_E_PARAM_HANDLE, CRYPTO_E_PARAM_HANDLE), así como transferencias de punteros nulos [SWS_CryIf_00076], [SWS_CryIf_00134], [SWS_Crypto_00196], [SWS_Crypto_00217].

Las sobrecargas de tiempo de ejecución y los cuellos de botella de recursos se interceptan de forma determinista mediante valores de retorno definidos. Si la cola del CSM para un job asíncrono se agota, el CSM rechaza la orden con el código de estado CRYPTO_E_BUSY y genera el error de tiempo de ejecución CSM_E_QUEUE_FULL [SWS_Csm_00018], [SWS_Csm_01089]. Si un búfer de resultados proporcionado está dimensionado de forma insuficiente, el controlador cancela la operación con CRYPTO_E_SMALL_BUFFER [SWS_Crypto_00195]. Si un servicio criptográfico hace referencia a una clave no inicializada o invalidada explícitamente (por ejemplo, tras invocar Csm_JobKeySetInvalid() o Crypto_KeySetInvalid()), las solicitudes de servicio fallan de manera controlada con CRYPTO_E_KEY_NOT_VALID o CRYPTO_E_KEY_EMPTY [SWS_Csm_91002], [SWS_CryIf_91003], [SWS_Crypto_91020].

Los mecanismos de degradación y fallback se habilitan a nivel de sistema: las aplicaciones pueden comprobar el estado de integridad de las claves antes de transmitir una orden a través de Csm_KeyGetStatus() [SWS_Csm_91047], [SWS_CryIf_91012]. En caso de que un acelerador criptográfico de hardware esté permanentemente ocupado o falle, la configuración de canales del CryIf permite una ruta alternativa basada en software, siempre que esté integrado un controlador de software redundante SWS_CryptoDriver p. 15.