módulo ara::crypto — Cryptography

El cluster funcional Cryptography proporciona servicios de seguridad estandarizados para cifrado simétrico y asimétrico, verificación de firmas, así como gestión segura de claves y certificados (PlatformDesign p. 71). El acceso a las operaciones criptográficas y a las ubicaciones de clave persistentes se realiza de forma estrictamente aislada a través de proveedores específicos de la plataforma y especificadores de instancia fijados declarativamente en el manifiesto (SWS Cryptography p. 39). La aplicación de restricciones de uso evita en este proceso el compromiso del material de clave sensible ([SWS_CRYPT_50092]).

más ›

El cluster funcional Cryptography (ara::crypto) proporciona una arquitectura de seguridad integral para la AUTOSAR Adaptive Platform (PlatformDesign p. 71). Para protegerse contra aplicaciones de usuario comprometidas, el almacenamiento de claves y la ejecución criptográfica se encapsulan normalmente en un demonio de plataforma aislado o en un módulo de seguridad de hardware (HSM) (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87). La funcionalidad completa se divide en CryptoProvider especializadas para primitivas de cálculo, el área de Key Storage para ubicaciones de clave persistentes (KeySlots), así como un X509Provider a escala de máquina para la gestión de certificados PKI (SWS Cryptography p. 39).

Diagrama de contexto: relaciones de arquitectura y componentes del Functional Cluster Cryptography entre aplicación, demonio y proveedores. Fuentes: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Las aplicaciones generan contextos criptográficos como cifradores simétricos ([SWS_CRYPT_20742]), cifradores autenticados ([SWS_CRYPT_20745]), funciones hash ([SWS_CRYPT_20747]) o instancias de firmante y verificador ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) a través de su proveedor (AUTOSAR AP EXP SWArchitecture p. 99). El procesamiento sigue un ciclo de vida determinista: tras la vinculación de clave (SetKey), la transformación se inicia mediante Start(), se transmite vía streaming a través de Update() y se concluye con Finish() (AUTOSAR AP TR SystemTests p. 206, EXP SWArchitecture p. 104). AllowedUsageFlags inmutables impiden eficazmente un uso no autorizado de las claves ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests p. 177).

Diagrama de estados: ciclo de vida de los contextos de transformación criptográfica desde la asignación hasta el restablecimiento. Fuentes: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Los certificados y las CSR se gestionan mediante el X509Provider ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), mientras que los contextos de validación comprueban cadenas de certificados teniendo en cuenta listas de revocación CRL ([SWS_CRYPT_50183]) y respuestas OCSP ([SWS_CRYPT_50124]) (AUTOSAR AP TR SystemTests p. 194). La asignación de KeySlots y certificados a las aplicaciones se efectúa de forma basada en modelos en el manifiesto mediante InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification p. 245, AUTOSAR AP TPS ManifestSpecification p. 649). Todas las interfaces funcionan con retornos ara::core::Result sin excepciones y señalan errores a través de la CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography p. 208).

más ›

Arquitectura, dominios de seguridad y aislamiento mediante demonio

El cluster funcional Cryptography (ara::crypto) constituye la base de seguridad central de la AUTOSAR Adaptive Platform y proporciona mecanismos criptográficos básicos, gestión de claves, así como servicios de certificados (PlatformDesign p. 71). De acuerdo con el modelo de confianza de la plataforma, los clusters funcionales de la plataforma pertenecen al fundamento de confianza, mientras que las Adaptive Applications se ejecutan en el espacio de usuario no privilegiado (SWS Cryptography p. 37). Para proteger de forma eficaz el material de clave y las operaciones criptográficas incluso ante un compromiso potencial de una aplicación, la arquitectura está concebida habitualmente basada en demonios; la ejecución efectiva y el almacenamiento de claves permanecen en un proceso de plataforma aislado o en un entorno de ejecución seguro (AUTOSAR AP EXP SWArchitecture p. 97, SWS Cryptography p. 87).

La arquitectura subdivide la funcionalidad criptográfica en tres dominios primarios: el CryptoProvider para primitivas de cálculo y transformaciones de clave, el área de Key Storage (ara::crypto::keys) para el mantenimiento persistente de objetos, así como el X509Provider (ara::crypto::x509) para la gestión de certificados (SWS Cryptography p. 39, SWS Cryptography p. 87). En una ECU pueden coexistir en paralelo varias instancias especializadas de CryptoProvider, por ejemplo para la conexión de diferentes módulos de seguridad de hardware (HSM, TPM) o controladores basados en software (SWS Cryptography p. 39). Sin embargo, entre diferentes proveedores no existe interoperabilidad deliberadamente: un objeto criptográfico o una clave pertenece exactamente a un proveedor y no puede ser procesado por otro proveedor (SWS Cryptography p. 39). Este encapsulamiento estricto se debe presumiblemente, de forma primordial, a que los dominios de seguridad de hardware fuerzan físicamente sus límites de clave y los identificadores de clave no son válidos entre distintos dominios. Pregunta Q-63efe107cf111983 (abierta)

Diagrama de contexto: relaciones de arquitectura y componentes del Functional Cluster Cryptography entre aplicación, demonio y proveedores. Fuentes: SWS Cryptography p. 39, PlatformDesign p. 71, AUTOSAR AP EXP SWArchitecture p. 97.

Puntos de entrada e inicialización de los proveedores criptográficos

La entrada al módulo se realiza mediante funciones de entrada globales que sirven como factorías para las interfaces de abstracción centrales (SWArchitecture p. 71). Las aplicaciones crean o cargan una instancia de un CryptoProvider a través de la función [SWS_CRYPT_20099] especificando un ara::core::InstanceSpecifier modelado. Para la gestión de certificados existe en todo el sistema exactamente un proveedor global de certificados, que se carga mediante [SWS_CRYPT_40099] (SWS Cryptography p. 39). De forma complementaria, están disponibles servicios auxiliares globales, entre ellos la generación directa de datos aleatorios a través de [SWS_CRYPT_30098], así como la consulta de un contador de seguridad asistido por hardware mediante [SWS_CRYPT_20098] (SWArchitecture p. 71).

Los recursos de clave persistentes no se instancian directamente, sino que se cargan a través de ubicaciones de clave lógicas (KeySlots). Para ello, el entorno de ejecución proporciona las funciones [SWS_CRYPT_50004] para accesos de solo lectura y [SWS_CRYPT_50005] para ubicaciones de clave con permisos de escritura, las cuales validan el identificador de instancia transferido frente a la configuración de autorizaciones (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649). A través de una instancia de KeySlot obtenida, se puede consultar la instancia de proveedor asignada mediante [SWS_CRYPT_30403], garantizando así la estrecha vinculación entre el lugar de almacenamiento y el entorno de ejecución (SWS Cryptography p. 39).

En cuanto se dispone de una instancia de CryptoProvider, esta actúa como factoría central para la instanciación de contextos de trabajo criptográficos específicos (AUTOSAR AP EXP SWArchitecture p. 99). Entre los contextos que se pueden crear se incluyen, entre otros, contextos para generadores de números aleatorios ([SWS_CRYPT_20741]), cifradores de bloque y de flujo simétricos ([SWS_CRYPT_20742]), cifrado autenticado ([SWS_CRYPT_20745]), códigos de autenticación de mensajes ([SWS_CRYPT_20746]), funciones hash criptográficas ([SWS_CRYPT_20747]), cifrado y descifrado asimétrico ([SWS_CRYPT_20750], [SWS_CRYPT_20751]), así como contextos de firma y verificación ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture p. 99).

Contextos de transformación criptográfica y procesamiento de datos

El procesamiento de datos criptográficos en ara::crypto sigue un ciclo de vida estrictamente basado en estados que garantiza el desacoplamiento de la configuración de algoritmos, la vinculación de claves y el procesamiento en streaming (AUTOSAR AP TR SystemTests p. 211). Tras la asignación del contexto mediante el proveedor, este se encuentra inicialmente en el estado no inicializado. Solo mediante la transferencia de una clave compatible a través de las sobrecargas específicas de tipo de SetKey() —por ejemplo, para claves simétricas ([SWS_CRYPT_23911]), claves privadas ([SWS_CRYPT_23515]) o directamente desde un KeySlot ([SWS_CRYPT_50043])— el contexto pasa al estado listo (AUTOSAR AP TR SystemTests p. 206).

Para procesamientos en streaming, la transformación se inicia mediante Start(), opcionalmente pasando un vector de inicialización o un contexto ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). A continuación, los bloques de datos se pueden alimentar paso a paso a través de Update() ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). En el cifrado autenticado (AEAD), la interfaz distingue estrictamente entre los datos asociados, procesados mediante [SWS_CRYPT_20313], y los datos útiles confidenciales a través de [SWS_CRYPT_50074] (EXP SWArchitecture p. 104). La conclusión de una transformación se realiza a través de Finish() o FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), tras lo cual se pueden leer etiquetas de autenticación o sumas de comprobación a través de GetDigest() ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

Además del modo de streaming, las clases de contexto como cifradores simétricos y cifradores autenticados admiten llamadas únicas compactas a través de [SWS_CRYPT_50047] o [SWS_CRYPT_50078], lo que permite cifrar o descifrar payloads cortos de manera eficiente sin una invocación de protocolo de múltiples fases (SWS Cryptography p. 58). Si se desea cancelar una operación en curso, una llamada a Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) o Reset() ([SWS_CRYPT_50212]) devuelve el contexto de manera determinista al estado inicial saneado (EXP SWArchitecture p. 100).

Diagrama de estados: ciclo de vida de los contextos de transformación criptográfica desde la asignación hasta el restablecimiento. Fuentes: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Gestión de claves, encapsulamiento y aplicación de autorizaciones

Las claves criptográficas se tipifican en el modelo de objetos como CryptoObject o RestrictedUseObject (AUTOSAR AP EXP SWArchitecture p. 111, EXP SWArchitecture p. 111). El estándar de la plataforma distingue entre claves simétricas (SymmetricKey), claves privadas asimétricas (PrivateKey) y claves públicas (PublicKey) (SWS Cryptography p. 291). El material de clave se puede generar directamente mediante el CryptoProvider ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) o derivarse a partir de material de clave existente parametrizando un KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) con una clave base y ejecutándolo mediante [SWS_CRYPT_21515] (EXP SWArchitecture p. 108).

Para aplicar el principio de privilegios mínimos, cada objeto de clave contiene restricciones de uso inmutables (AllowedUsageFlags) que se pueden consultar mediante [SWS_CRYPT_50092] (AUTOSAR AP TR SystemTests p. 177). La pila criptográfica valida en cada intento de vinculación (SetKey) si la operación del contexto de destino (p. ej., cifrar, firmar, derivar o exportar) está autorizada por los flags de la clave, y rechaza estrictamente los usos no permitidos (AUTOSAR AP TR SystemTests p. 177, SWArchitecture p. 95). La asignación predeterminada para un algoritmo se puede determinar mediante [SWS_CRYPT_20955].

Para el intercambio seguro de claves, el módulo implementa varios procedimientos estandarizados: en el acuerdo de claves asimétrico (Diffie-Hellman / ECDH), se crea a través de [SWS_CRYPT_20758] un KeyAgreementPrivateCtx al que se vincula la clave privada ([SWS_CRYPT_21313]); a continuación, el método [SWS_CRYPT_21312] calcula la clave simétrica de destino compartida teniendo en cuenta la clave pública del extremo remoto (AUTOSAR AP TR SystemTests p. 179). En el Key Encapsulation Mechanism (KEM), un KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) encapsula una clave simétrica mediante [SWS_CRYPT_21813], mientras que el extremo remoto realiza el desencapsulamiento a través de un KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) mediante [SWS_CRYPT_21412] (AUTOSAR AP TR SystemTests p. 173, AUTOSAR TR AdaptivePlatformSystemTests p. 188). Para el transporte protegido de claves se encuentran disponibles Key Wrapping ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) y exportación asegurada ([SWS_CRYPT_20728]) (AUTOSAR AP TR SystemTests p. 174, AUTOSAR AP TR SystemTests p. 182).

Diagrama de secuencias: acuerdo asimétrico de claves mediante Diffie-Hellman y derivación de claves útiles simétricas. Fuentes: [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests p. 179.

Las firmas asimétricas se procesan mediante contextos separados: la firma se efectúa a través de un SignerPrivateCtx ([SWS_CRYPT_20756]) y el método [SWS_CRYPT_23512], mientras que la verificación se lleva a cabo mediante un VerifierPublicCtx ([SWS_CRYPT_20757]) y el método [SWS_CRYPT_24112] (AUTOSAR AP TR SystemTests p. 164, SWArchitecture p. 84). Si un KeySlot se actualiza en segundo plano mediante servicios de gestión privilegiados (p. ej., renovación de claves OTA), las bibliotecas consumidoras pueden ser notificadas a través de un observador de actualización mediante [SWS_CRYPT_30404] para recargar su material de clave de forma síncrona (AUTOSAR AP SWS Cryptography p. 36).

Diagrama de secuencias: flujo de generación y verificación de firmas mediante el uso de contextos privados y públicos independientes. Fuentes: [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests p. 164.

Gestión de certificados X.509, validación y grupos

El subsistema ara::crypto::x509 proporciona funciones estandarizadas para infraestructuras de clave pública (PKI) (EXP SWArchitecture p. 116). El X509Provider central ([SWS_CRYPT_40099]) admite tanto memoria de sesión volátil como almacenamientos persistentes (SWS Cryptography p. 39). Los certificados y las cadenas se analizan sintácticamente desde búferes de bytes mediante [SWS_CRYPT_40614] o [SWS_CRYPT_40616]. Para solicitar nuevos certificados de identidad, las aplicaciones pueden generar Certificate Signing Requests (CSR) firmadas criptográficamente a través de [SWS_CRYPT_40640], pasando el contexto del firmante y el nombre distinguido (DN) mediante [SWS_CRYPT_50186] (AUTOSAR AP TR SystemTests p. 189).

Para la verificación de conformidad y validez, la aplicación instancia un CertificateValidationCtx a través de [SWS_CRYPT_50125]. A este contexto se le añaden anclas de confianza (Trust Anchors) mediante [SWS_CRYPT_50117], se definen opciones de validación a través de [SWS_CRYPT_50120] y se almacenan marcas de tiempo de referencia mediante [SWS_CRYPT_50121]. La verificación jerárquica de la cadena frente a la cadena de confianza se realiza a través de [SWS_CRYPT_50122] o [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests p. 194). Para la detección de revocaciones de certificados, se pueden importar listas de revocación de certificados (CRL) ([SWS_CRYPT_50183]) o incorporar consultas de estado de certificados en línea (OCSP según RFC 6960) en el estado de validación a través de [SWS_CRYPT_40626], [SWS_CRYPT_50185] y [SWS_CRYPT_50124] (AUTOSAR AP TR SystemTests p. 194).

Para desacoplar a los consumidores de certificados de las instancias individuales de certificados en los cambios de clave, el manifiesto admite el concepto de CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification p. 657). Las aplicaciones consumidoras cargan a través de [SWS_CRYPT_50126] el grupo completo de certificados vinculados lógicamente, mientras que los servicios de administración privilegiados pueden intercambiar dinámicamente o depurar certificados a través de [SWS_CRYPT_50127] y [SWS_CRYPT_50128] (AUTOSAR AP TPS ManifestSpecification p. 657).

Diagrama de secuencia: validación de certificados X.509 con cadena de certificados, importación de CRL y comprobación de estado OCSP en línea. Fuentes: [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests p. 194.

Modelado de manifiestos, interfaces de puerto y despliegue

La integración de recursos criptográficos en una arquitectura global del vehículo se realiza de forma declarativa a través del metamodelo AUTOSAR en el manifiesto ARXML (AUTOSAR AP TPS ManifestSpecification p. 244). Los componentes de software modelan sus requisitos de seguridad en el nivel de diseño a través de puertos (RPortPrototype), los cuales se tipifican mediante especializaciones de CryptoInterface: CryptoKeySlotInterface para ubicaciones de claves, CryptoCertificateInterface para recursos de certificados y CryptoProviderInterface para el acceso a proveedores de ejecución (TPS ManifestSpecification p. 167, AUTOSAR AP TPS ManifestSpecification p. 245). Los atributos de las interfaces determinan de forma invariable si se conceden derechos de lectura o escritura (writeAccess) y qué tipos de objetos están permitidos (TPS ManifestSpecification p. 168, TPS ManifestSpecification p. 438).

En el manifiesto de despliegue, la configuración de destino (Target Configuration) conecta los prototipos de puerto abstractos con recursos físicos concretos de la plataforma (AUTOSAR AP TPS ManifestSpecification p. 649). El elemento del metamodelo CryptoKeySlotToPortPrototypeMapping mapea el puerto de un proceso a un CryptoKeySlot declarado en el CryptoModuleInstantiation de la máquina (TPS ManifestSpecification p. 614, TPS ManifestSpecification p. 646). De manera análoga, CryptoCertificateToPortPrototypeMapping asigna certificados (TPS ManifestSpecification p. 655). En tiempo de ejecución, la ruta del puerto en el manifiesto representa el ara::core::InstanceSpecifier que el código de aplicación pasa a funciones de carga como [SWS_CRYPT_50004] (ManifestSpecification p. 154).

Para las interacciones de plataforma entre clústeres funcionales —por ejemplo, entre Communication Management (SecOC, IPsec, TLS) y la pila criptográfica— no existen prototipos de puerto clásicos (TPS ManifestSpecification p. 861). Aquí, el InstanceSpecifier se forma en su lugar mediante elementos derivados de FunctionalClusterInteractsWithFunctionalClusterMapping, por ejemplo ComKeyToCryptoKeySlotMapping o SecOcJobMapping (TPS ManifestSpecification p. 861, TPS ManifestSpecification p. 864, ManifestSpecification p. 411). También la protección de persistencia (Persistency Deployment) y las sumas de comprobación de clústeres de software integran sus claves y proveedores a través de estos mapeos estandarizados de manifiesto (TPS ManifestSpecification p. 867, TPS ManifestSpecification p. 896).

Comportamiento en caso de error

El concepto de tratamiento de errores del módulo criptográfico sigue las estrictas directrices de la Adaptive Platform para código seguro frente a fallos y sin excepciones (noexcept) (SWS Cryptography p. 145). Todas las operaciones síncronas devuelven situaciones de error a través del tipo de resultado genérico ara::core::Result<T, ara::core::ErrorCode> (SWS Cryptography p. 208). Los códigos de error están anclados en un dominio de error propio, representado mediante [SWS_CRYPT_19902]; su nombre se puede consultar a través de [SWS_CRYPT_19950] y la descripción textual del error mediante [SWS_CRYPT_19953]. Para aplicaciones que utilizan explícitamente el tratamiento de excepciones, la pila proporciona el tipo de excepción CryptoException ([SWS_CRYPT_19906]) y la función auxiliar [SWS_CRYPT_19954].

Los códigos de error funcionales típicos abarcan violaciones de contexto como CryptoErrc::kUninitializedContext, cuando se inician operaciones criptográficas antes de la invocación de SetKey(), o CryptoErrc::kInvalidInputSize, cuando los búferes de datos de entrada transferidos no coinciden con la trama de bloques requerida (SWS Cryptography p. 208). En procesos de serialización y conversión, CryptoErrc::kUnknownIdentifier señala valores de argumento no admitidos y CryptoErrc::kIncompatibleArguments combinaciones de parámetros incompatibles (SWS Cryptography p. 145). Al acceder a recursos de claves, la pila impide accesos no autorizados devolviendo kAccessViolation (SWS Cryptography p. 87). Al analizar extensiones de certificados X.509 personalizadas defectuosas, el analizador sintáctico se interrumpe con CryptoErrc::kRuntimeFault (SWS Cryptography p. 280, SWS Cryptography p. 356).

Para restaurar un estado definido en el contexto tras producirse un error y evitar fugas de memoria o búferes de streaming bloqueados en el demonio, el llamador debe limpiar el contexto. Esto se realiza de manera específica invocando Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), con lo que se descartan transformaciones no finalizadas, o bien mediante Reset() ([SWS_CRYPT_50212]), lo que devuelve el contexto por completo al estado previo a la vinculación de claves (EXP SWArchitecture p. 100).

Más evidencia detallada

La especificación del módulo Cryptography se fundamenta en una serie de requisitos centrales y documentos de arquitectura, que se clasifican a continuación:

• Puntos de entrada globales y fábricas: las especificaciones [SWS_CRYPT_20099] (LoadCryptoProvider) y [SWS_CRYPT_40099] (LoadX509Provider) definen el acceso normativo a los dos dominios de proveedores primarios (SWArchitecture p. 71, SWS Cryptography p. 39).
• Almacenamiento de claves y vinculación de puertos: las funciones [SWS_CRYPT_50004] (LoadKeySlot) y [SWS_CRYPT_50005] (LoadWriteableKeySlot) implementan de forma vinculante la interacción entre el modelado de puertos en el manifiesto y el acceso aislado a memoria física en el KSP (SWS Cryptography p. 87, AUTOSAR AP TPS ManifestSpecification p. 649).
• Fábricas de primitivas y contextos: el grupo de interfaces en torno a [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx) y [SWS_CRYPT_20757] (CreateVerifierPublicCtx) establece la creación dinámica de máquinas de estado estandarizadas para trabajos criptográficos (AUTOSAR AP EXP SWArchitecture p. 99, AUTOSAR AP TR SystemTests p. 164).
• Validación de X.509 y comprobación de revocación: con [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl) y [SWS_CRYPT_50124] (AddOcspResponse) se estandariza una cadena de comprobación de PKI completa y apta para automoción (AUTOSAR AP TR SystemTests p. 194, EXP SWArchitecture p. 116).