Auditoría y selección de dependencias criptográficas

La biblioteca criptográfica que elija es una de las decisiones de seguridad más trascendentales de un proyecto. Incluso los desarrolladores que actúan con buena intención pueden crear sistemas inseguros si utilizan una biblioteca deficiente. Por el contrario, una biblioteca bien diseñada dificulta la comisión de errores catastróficos. El proceso de selección debe ser sistemático y evaluar el historial de seguridad, el diseño de la API, el estado del mantenimiento y la adecuación al propósito.

Una de las primeras preguntas sobre cualquier biblioteca criptográfica es cuándo se auditó de forma independiente por última vez y qué abarcó esa auditoría. Una auditoría realizada hace cinco años sobre la versión 1.0 ofrece menos garantías para la versión 3.0 que se utiliza actualmente. Busque auditorías realizadas por empresas de seguridad acreditadas (NCC Group, Trail of Bits, Quarkslab, Cure53) que cubran la funcionalidad específica que planea utilizar. Algunas bibliotecas publican los informes de auditoría; la ausencia de cualquier auditoría es un factor de riesgo importante.

Revise el historial de CVE de la biblioteca en la NVD (National Vulnerability Database). Examine cuántos CVE existen, sus niveles de gravedad, qué clases de vulnerabilidades representan (errores lógicos, corrupción de memoria o debilidades de los algoritmos) y con qué rapidez publicaron los responsables los parches. Una biblioteca con CVE ocasionales que se corrigen rápidamente demuestra un mantenimiento receptivo. Una biblioteca con muchos CVE de gravedad alta o con parches lentos es una señal de alarma.

Las bibliotecas criptográficas sin mantenimiento son peligrosas. Compruebe la fecha del último commit, la frecuencia de las versiones y si se están atendiendo los avisos de seguridad. Una biblioteca cuyo último commit se realizó hace tres años puede tener vulnerabilidades conocidas que nunca se corregirán. El tamaño de la comunidad es importante por la amplitud de las revisiones: las bibliotecas ampliamente utilizadas reciben un análisis más exhaustivo de los investigadores de seguridad que los proyectos especializados.

Una superficie de API más reducida y con decisiones predefinidas ofrece mayor seguridad. Las bibliotecas que exponen muchas opciones de algoritmos y parámetros de configuración crean oportunidades para configurarlas incorrectamente. Compare libsodium (una función por caso de uso y un algoritmo fijo) con OpenSSL EVP (donde debe elegir por separado el cifrador, el modo, el tamaño de la clave, el relleno y la gestión del IV). Cuanto más difícil sea utilizar incorrectamente una biblioteca, más adecuada será para proyectos que priorizan la seguridad.

En las operaciones que implican datos secretos (comparación de claves, descifrado y verificación de firmas), la implementación debe utilizar algoritmos en tiempo constante que no realicen bifurcaciones ni accedan a la memoria basándose en valores secretos. Verifique que la documentación de la biblioteca indique explícitamente garantías de tiempo constante para las operaciones sensibles o que el código fuente utilice funciones aprobadas de comparación en tiempo constante. Las bibliotecas que no ofrecen esta garantía son vulnerables a ataques de canal lateral basados en la temporización.

Una buena biblioteca criptográfica debe admitir algoritmos modernos y tener previsto retirar los obsoletos. Debe ofrecer ChaCha20-Poly1305 o AES-256-GCM para el cifrado, Ed25519 o ECDSA P-256 para las firmas, X25519 para el intercambio de claves y Argon2id para aplicar funciones hash a las contraseñas. Las bibliotecas que solo ofrecen algoritmos heredados (DES, RC4, MD5, SHA-1) no son adecuadas para implementaciones nuevas, independientemente de sus demás características.

Evalúe las dependencias transitivas: ¿de qué bibliotecas depende su biblioteca criptográfica y cuál es su postura de seguridad? Una biblioteca sin dependencias externas (como libsodium) presenta un riesgo mínimo para la cadena de suministro. Una biblioteca que depende de una docena de paquetes npm, cada uno con sus propias dependencias, tiene una gran superficie de ataque en la cadena de suministro. Compruebe si la biblioteca utiliza compilaciones reproducibles, que permiten verificar que el binario distribuido coincide con el código fuente.

Las industrias reguladas (sanidad, finanzas y administración pública) suelen exigir módulos criptográficos validados según FIPS 140-2 o 140-3. La validación FIPS es costosa y requiere mucho tiempo, por lo que solo un subconjunto de bibliotecas la tiene. OpenSSL con su proveedor FIPS, BoringCrypto (utilizado en crypto/tls de Go) y algunas bibliotecas para HSM cuentan con validación FIPS. Si su implementación debe cumplir con FIPS, este requisito reduce considerablemente las opciones de biblioteca.

Los módulos de seguridad de hardware (HSM) y los servicios KMS en la nube suelen tener API propietarias para las operaciones con claves. Acoplar estrechamente su aplicación a AWS KMS o a un proveedor específico de HSM crea un riesgo de dependencia del proveedor. Evalúe si la biblioteca proporciona capas de abstracción (como la integración de KMS de Tink) que permitan cambiar de proveedor. Considere también que, si el proveedor de HSM deja de ofrecer soporte o aumenta los precios, los costes de migración podrían ser considerables.

La regla más importante al seleccionar dependencias criptográficas es utilizar bibliotecas conocidas y ampliamente utilizadas que implementen estándares consolidados, y no implementar nunca primitivas criptográficas por su cuenta. Por muy bien que comprenda la teoría, implementar correctamente AES, RSA, operaciones con curvas elípticas o cifrado autenticado en código de producción es extremadamente difícil y casi nunca compensa el riesgo frente al uso de una biblioteca probada.

Lista de comprobación para seleccionar una biblioteca: compruebe el alcance y el informe de una auditoría independiente reciente, revise el historial de CVE y el tiempo de respuesta a los parches, verifique el mantenimiento activo y la participación de la comunidad, prefiera superficies de API más reducidas que dificulten el uso incorrecto, confirme las garantías de tiempo constante para las operaciones sensibles, asegúrese de que admita algoritmos modernos, evalúe las dependencias de la cadena de suministro, compruebe la validación FIPS si está en un sector regulado, considere el riesgo de dependencia del proveedor de KMS y utilice siempre bibliotecas consolidadas en lugar de implementar primitivas.