Un paso criptográfico omitido en la implementación del cifrado CCM permite falsificar mensajes autenticados cuando no se usan datos asociados.
Una vulnerabilidad en la biblioteca criptográfica Bouncy Castle para .NET (bc-csharp) compromete la integridad de mensajes cifrados bajo el estándar ucraniano DSTU 7624 en modo CCM. El defecto, catalogado como CVE-2026-16000 y corregido en la versión 2.7.0, permite que un atacante que observe tráfico cifrado de contenido conocido o elegido pueda fabricar mensajes falsos con etiquetas de autenticación válidas. La falla afecta exclusivamente a aplicaciones que invocan directamente el componente KCcmBlockCipher sin proporcionar datos asociados — un escenario de uso poco común pero crítico cuando se presenta.
Cómo un bloque faltante rompió la cadena de autenticación
El problema reside en la implementación del modo CCM (Counter with CBC-MAC) del algoritmo de cifrado por bloques DSTU 7624, el estándar nacional de Ucrania para cifrado simétrico. En una implementación correcta de CCM, el primer bloque procesado — conocido como G1 — debe vincular tres elementos críticos en el cálculo del CBC-MAC: el nonce (número usado una sola vez), la longitud del mensaje y los flags de parámetros de configuración. Esta vinculación garantiza que cada mensaje cifrado esté atado de forma única a su contexto de cifrado.
La implementación defectuosa en bc-csharp procesaba el bloque G1 únicamente cuando la aplicación proporcionaba datos asociados (información adicional que se autentica pero no se cifra). Sin datos asociados, el código omitía este paso y calculaba la etiqueta de autenticación como un CBC-MAC directo del texto plano, completamente independiente del nonce. En la práctica, esto significa que el mismo mensaje cifrado con diferentes nonces produce la misma etiqueta de autenticación — una violación fundamental de las garantías del modo CCM.
El alcance limitado que no reduce el riesgo para quien lo sufre
La vulnerabilidad no afecta a la mayoría de las aplicaciones que usan Bouncy Castle. El componente KCcmBlockCipher es una interfaz de bajo nivel que requiere invocación directa — la mayoría de los desarrolladores usan abstracciones de más alto nivel que manejan datos asociados por defecto. Además, el estándar DSTU 7624 tiene adopción limitada fuera de Ucrania y algunos países de Europa del Este, lo que reduce la superficie de exposición global.
Sin embargo, para las aplicaciones que sí cumplen ambas condiciones — uso directo de KCcmBlockCipher y ausencia de datos asociados — el impacto es total. Un atacante con capacidad de observar tráfico cifrado (por ejemplo, en un canal de comunicación comprometido) puede recolectar pares de texto plano conocido y su correspondiente texto cifrado. Con esta información, puede construir mensajes falsos que pasarán la verificación de autenticidad en el receptor, permitiendo ataques de inyección de comandos, manipulación de transacciones o suplantación de identidad según el contexto de la aplicación.
Por qué América Latina no usa DSTU 7624 pero sí usa Bouncy Castle
El estándar DSTU 7624 no tiene presencia documentada en implementaciones críticas de América Latina — la región se apoya mayoritariamente en AES para cifrado simétrico y en estándares NIST o ISO para modos de operación. No hay registros públicos de organismos gubernamentales, entidades financieras o proveedores de infraestructura crítica en México, Brasil, Argentina, Chile o Colombia que hayan adoptado el estándar ucraniano en sistemas de producción.
La exposición regional pasa por otro lado: Bouncy Castle es una de las bibliotecas criptográficas más utilizadas en el ecosistema .NET, presente en aplicaciones empresariales, plataformas de pago, sistemas de firma digital y backends de servicios cloud desarrollados en la región. Aunque la mayoría de estas implementaciones usan AES-GCM o ChaCha20-Poly1305 en lugar de DSTU 7624, la presencia de código vulnerable en dependencias puede abrir vectores de ataque indirectos — por ejemplo, si un módulo legacy o una integración con sistemas de Europa del Este invoca KCcmBlockCipher sin que el equipo de desarrollo local lo sepa. La ausencia de severidad asignada por NVD (marcada como N/A) puede llevar a que esta actualización no se priorice en ciclos de parcheo, dejando la ventana abierta más tiempo del necesario.
La actualización que cierra el hueco sin romper compatibilidad
Legion of the Bouncy Castle Inc. publicó la versión 2.7.0 de bc-csharp con la corrección del defecto. El parche modifica KCcmBlockCipher para procesar el bloque G1 en todos los casos, independientemente de si se proporcionan datos asociados o no. La corrección no introduce cambios en la API pública ni requiere modificaciones en el código de las aplicaciones que usan la biblioteca — la actualización es un reemplazo directo de la dependencia.
La ausencia de calificación de severidad en la base de datos del NVD refleja probablemente la combinación de alcance limitado (uso directo de un componente de bajo nivel) y contexto de aplicación específico (ausencia de datos asociados). Sin embargo, para las aplicaciones afectadas, la explotabilidad es alta: no requiere interacción del usuario, no necesita privilegios especiales y puede ejecutarse de forma remota si el atacante tiene acceso al tráfico de red. La falta de un score CVSS no debería interpretarse como baja criticidad — es más bien un reflejo de que el impacto depende completamente del contexto de implementación.
Nuestro análisis
Este caso ilustra un patrón recurrente en vulnerabilidades criptográficas: la diferencia entre una implementación que funciona en la mayoría de los casos y una que cumple la especificación en todos los casos. El código defectuoso en bc-csharp probablemente pasó pruebas unitarias y validación funcional — el modo CCM funcionaba correctamente cuando se usaba con datos asociados, que es el caso de uso más común y el que aparece en los ejemplos de documentación. El problema solo se manifestaba en un escenario de borde que muchos desarrolladores nunca encuentran.
La omisión del bloque G1 sin datos asociados no es un error de implementación menor — es una violación de la especificación del modo CCM que destruye una de sus garantías fundamentales: la vinculación entre el nonce y la autenticación. Esta clase de defectos es particularmente peligrosa porque no produce errores visibles: el cifrado y descifrado funcionan, las etiquetas se verifican correctamente, pero la seguridad prometida por el algoritmo no existe. Un atacante que entienda la falla puede explotarla sin dejar rastros en logs de errores o sistemas de detección de intrusiones.
¿Cuántas otras implementaciones de modos de cifrado autenticado en bibliotecas ampliamente desplegadas tienen defectos similares que solo se manifiestan en combinaciones específicas de parámetros que nadie probó sistemáticamente?